Re: Z114 to z14 experience any ?

[Timothy Sipples]

Dana Mitchell wrote:
>We are currently on z114's  and will probably migrate to z14
>zr1's,  and the coupling link situation is our biggest stumbling
>block.  Since there is no common coupling link available between
>z114-z14,  it will require us to move the entire plex at once,
>not rolling onto new hardware, one LPAR at a time as we have in
>the past.

There is a possible workaround for that. It involves using a z13s machine
as a "bridge." It's basically the same process as migrating a Parallel
Sysplex to the z13s, followed by a migration to the z14 ZR1 -- two
back-to-back jumps. To do that you'd simply need a suitably configured z13s
machine on a temporary basis, and assuming you've got the correct
attachments and features on your z114. There's a cost involved since you
need the z13s machine inserted into the overall migration for a short
period of time, but it's available. IBM is still building z13s machines and
will for several more months, and the z114 to z13s MES is still available
-- that's one way to get your temporary z13s.

I have worked with shops that have taken this "double hop" approach, and it
works. It's not how you'd prefer to do things, but it can be done.

Or you can take the "big jump" approach if a planned outage is
tolerable, and there are usually ways to mitigate the effects of that
planned outage and/or to make that service interruption very short for your
most critical services.

Tom Brennan wrote:
>- FICON 16S cards can only negotiate down to 4G. If you have older 2G
>peripherals, that could be an issue.

If this is an absolute showstopper then "talk to your friendly IBM
representative" about whether it'd make sense to MES to a z13s then upgrade
to a z14 ZR1. FICON8 adapters barely survive that double transition, from
what I recall. But there would be a cost to that longer path, so I really
don't recommend it unless you've absolutely got to live with the 2 Gb/s
equipment.

>- Brocade Gen 4 switches are not supported for ZR1 and need to move to
>at least Gen 5.

You can *ask* for a RPQ; no guarantees. As I understand it, the fundamental
problem is that the Generation 4 equipment is soon falling out of support
for everybody, and Brocade understandably doesn't want you to slam into an
unsupported configuration almost immediately after you migrate.

>- Power for a ZR1 is single phase, basically meaning the old 3PH cords
>on the z114 can't be reused.

Yes, also the IBF (Internal Battery Feature) is not available for the z14
ZR1, so you'll want to make sure you're properly protected and configured
in your data center power systems if you're currently relying on the IBF.

Another thing that comes to mind is that you probably ought to take this
opportunity to shift to the 1U rack mount Hardware Management Console (HMC)
and, if you have it, TKE Workstation. And, if you wish, you can combine
these 1U rack mount features with Feature Code #0617, the 16U Reserved
feature, which allows you to mount up to 16U worth of equipment (HMCs, TKE
Workstations, and other items) into the IBM z14 ZR1 frame itself. If you
order FC0617 just make sure you're OK with the amount of remaining
expansion capacity you have for I/O and other adapters, but it's one of my
favorite new features in the new machine. This is also a great time to
review and improve the security practices and deployment configuration for
your HMC.

The z14 ZR1 does not support ESA/390 IPLs, so please check your inventory
of IPL'able items such as DFSMS recovery utilities, z/VM installation DVDs,
ZZSA, and old Linux distributions, as applicable, to make sure they're
modern enough. There's one available workaround for z/VSE 4.x: running
z/VSE 4.x under z/VM. And it's an unsupported but "as-is/known to work"
workaround. Otherwise, you've got to be "64-bit clean" from IPL. You don't
want to find yourself in a DR situation and unable to IPL some critical
tool associated with the recovery process.

Interrogate your IBM person to see if there are any free or nearly free
feature codes that look interesting, and grab them. For example, if you're
still missing the feature code for CPACF, and if it's orderable in your
country, grab it. (Why not?)


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: Broadcom to buy CA?

[Mike Schwab]

FCP / FICON switches under the name Brocade.

https://www.broadcom.com/company/oem-partners/fibre-channel-networking/ibm

On Wed, Jul 11, 2018 at 11:10 PM Jake Anderson  wrote:
>
> Broadcom do they have any Mainframe portfolio by chance ?
>
> On Thu 12 Jul, 2018, 5:29 AM Knutson, Samuel, 
> wrote:
>
> > Yes.
> >
> > Broadcom confirms $18.9B buyout of CA
> > https://seekingalpha.com/news/3369508
> >
> >
> > On Jul 11, 2018, at 5:49 PM, Edward Finnell <
> > 000248cce9f3-dmarc-requ...@listserv.ua.edu > 000248cce9f3-dmarc-requ...@listserv.ua.edu>> wrote:
> >
> >
> > https://www.barrons.com/articles/broadcom-tanks-on-report-itll-buy-ca-1531341964?mod=hp_RTA
> > The contents of this e-mail are intended for the named addressee only. It
> > contains information that may be confidential. Unless you are the named
> > addressee or an authorized designee, you may not copy or use it, or
> > disclose it to anyone else. If you received it in error please notify us
> > immediately and then destroy it
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Andrew Rowley]

On 12/07/2018 2:48 PM, Ed Jaffe wrote:


If you are referring to the GameMaker Language (GML) then yes, JCL is 
clearly much, much worse...


https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml%20language%20overview/ 




No, Generalized Markup Language i.e. SCRIPT.

--
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: Using JCL Symbld and TYPRUN=SCAN

[Ed Jaffe]

On 7/11/2018 9:27 PM, Andrew Rowley wrote:

On 12/07/2018 2:05 PM, Ed Jaffe wrote:


With all due respect to whomever deserves it, ANY instructions 
telling the computer what to do constitute programming...


That's sort of true, but it vastly expands the competition. It makes 
HTML, even GML programming languages. Is JCL a worse programming 
language than GML?


If you are referring to the GameMaker Language (GML) then yes, JCL is 
clearly much, much worse...


https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml%20language%20overview/

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


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

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Andrew Rowley]

On 12/07/2018 2:05 PM, Ed Jaffe wrote:


With all due respect to whomever deserves it, ANY instructions telling 
the computer what to do constitute programming...


That's sort of true, but it vastly expands the competition. It makes 
HTML, even GML programming languages. Is JCL a worse programming 
language than GML?


--
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: Deleting all members of a PDS

[Jesse 1 Robinson]

Yup. Security Pacific Bank. We used PDSCLEAN to launder everything. Old habits 
fade slowly. 

.
.
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 Ed Jaffe
Sent: Wednesday, July 11, 2018 9:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Deleting all members of a PDS

On 7/11/2018 7:04 PM, Jesse 1 Robinson wrote:
> I originally recommended PDSCLEAN to my colleague who was doing the 
> migration. Then realized that we don't have PDSCLEAN here; I was flashing 
> back to my previous shop.

Your previous shop?! How long ago was that? When we worked together back in the 
1980s?

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


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

Re: Broadcom to buy CA?

[Jake Anderson]

Broadcom do they have any Mainframe portfolio by chance ?

On Thu 12 Jul, 2018, 5:29 AM Knutson, Samuel, 
wrote:

> Yes.
>
> Broadcom confirms $18.9B buyout of CA
> https://seekingalpha.com/news/3369508
>
>
> On Jul 11, 2018, at 5:49 PM, Edward Finnell <
> 000248cce9f3-dmarc-requ...@listserv.ua.edu 000248cce9f3-dmarc-requ...@listserv.ua.edu>> wrote:
>
>
> https://www.barrons.com/articles/broadcom-tanks-on-report-itll-buy-ca-1531341964?mod=hp_RTA
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
> disclose it to anyone else. If you received it in error please notify us
> immediately and then destroy it
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Deleting all members of a PDS

[Ed Jaffe]

On 7/11/2018 7:04 PM, Jesse 1 Robinson wrote:

I originally recommended PDSCLEAN to my colleague who was doing the migration. 
Then realized that we don't have PDSCLEAN here; I was flashing back to my 
previous shop.


Your previous shop?! How long ago was that? When we worked together back 
in the 1980s?


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


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

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Ed Jaffe]

On 7/11/2018 4:04 PM, Pew, Curtis G wrote:
I don’t think it’s true that JCL is the worst programming language 
(with all due respect to Fred Brooks) because it isn’t really a 
programming language. Should it have been a programming language? 
Almost certainly, as shown by Unix scripting languages. But it isn’t...


With all due respect to whomever deserves it, ANY instructions telling 
the computer what to do constitute programming...


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


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

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Andrew Rowley]

On 12/07/2018 11:47 AM, Paul Gilmartin wrote:

On Thu, 12 Jul 2018 11:01:50 +1000, Andrew Rowley wrote:

Creating temporary files has its own security exposures. I am always
wary in case I am creating a security problem I don't understand.

You'd better not use SORT.
I am comfortable that the temporary file facilities in JCL are secure, 
and constructs like DISP=(NEW,DELETE) are not an issue. And temporary 
files created by something like DFSORT are someone else's problem.


It is temporary files in the HFS side of things that are the issue. 
Again it is something that we take for granted in JCL that becomes 
difficult to do correctly without it.


A couple of articles on the subject:
http://www.linuxsecurity.com/content/view/115462/81/
https://blogs.msdn.microsoft.com/secureapps/2007/01/22/temporary-file-generation-and-usage-best-practices/

There are enough issues there that for me, the best solution is point 1: 
Don't use tempfiles/Avoid temporary files altogether


--
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: Deleting all members of a PDS

[Jesse 1 Robinson]

I originally recommended PDSCLEAN to my colleague who was doing the migration. 
Then realized that we don't have PDSCLEAN here; I was flashing back to my 
previous shop. Yes, the program works fine. But DEL (*) does too, and it's 
certified.  

.
.
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 Lizette Koehler
Sent: Wednesday, July 11, 2018 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Deleting all members of a PDS

You might try using INFILE and specify a DD with DISP=SHR

Or got cbttape.org and download PDSCLEAN - works great for PDS and PDS/E 
datasets

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Jesse 1 Robinson
> Sent: Wednesday, July 11, 2018 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Deleting all members of a PDS
> 
> While installing a new version of the PDS command-one that works on 
> z/OS 2.3 as previously discussed here-we need to empty existing 
> libraries in order to refill them with new members. Without a working 
> PDS command, we had to find a different way to accomplish FIXPDS RESETDIR.
> 
> I finally remembered the relatively new DELETE pds-dsn(*), which 
> accomplishes the task nicely. However, like IDCAMS DELETE in general, 
> my testing indicates that it wants exclusive enqueue on the PDS. Not a 
> problem for most PDS data sets, but a link listed library must contend 
> with XCFAS and LLA. I know that both of those can be handled fairly 
> easily, but I'm curious if there's some additional keyword that will 
> ignore the SHR enqueues. I have not found anything.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.com


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

Re: Using JCL Symbld and TYPRUN=SCAN

[Paul Gilmartin]

On Thu, 12 Jul 2018 11:01:50 +1000, Andrew Rowley wrote:
>
>Creating temporary files has its own security exposures. I am always
>wary in case I am creating a security problem I don't understand.
> 
You'd better not use SORT.

-- gil

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

Re: Broadcom to buy CA?

[Knutson, Samuel]

Yes.

Broadcom confirms $18.9B buyout of CA https://seekingalpha.com/news/3369508


On Jul 11, 2018, at 5:49 PM, Edward Finnell 
<000248cce9f3-dmarc-requ...@listserv.ua.edu>
 wrote:

https://www.barrons.com/articles/broadcom-tanks-on-report-itll-buy-ca-1531341964?mod=hp_RTA
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Andrew Rowley]

On 12/07/2018 10:46 AM, Paul Gilmartin wrote:

Is it any worse than if the processes operated sequentially; no overlap.
Second guy wins.  Conscientious  second guy will create the file with
O_EXCL.  If you don't trust the second guy, lock him out with RACF profile
or file permissions.
It probably is worse, e.g. a likely example is where the second guy is 
processing the output from the first guy. The designers of z/OS thought 
this scenario was most likely an error and so protected you from it - I 
tend to agree.


I don't trust the second guy to get the serialization right, where it is 
not built-in.



If I want to be very nondisruptive I write to a temp name and rename at
the end.  This guarantees that no other job sees the update in transit.
Creating temporary files has its own security exposures. I am always 
wary in case I am creating a security problem I don't understand.


--
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: Using JCL Symbld and TYPRUN=SCAN

[Paul Gilmartin]

On Thu, 12 Jul 2018 09:40:50 +1000, Andrew Rowley wrote:
>
>On a unix system, you can open a file for writing and another process
>can delete it while you have it open and create a new file with the same
>name. The file you are writing disappears when you close it. 
>
That's a sort of LUW isolation, a facility that has come relatively recently to
z/OS in PDSE members.  For better or for worse, however you view it.
Is it any worse than if the processes operated sequentially; no overlap.
Second guy wins.  Conscientious  second guy will create the file with
O_EXCL.  If you don't trust the second guy, lock him out with RACF profile
or file permissions.

If I want to be very nondisruptive I write to a temp name and rename at
the end.  This guarantees that no other job sees the update in transit.
UNIX rename() is preemptive: it quietly replaces any older file with the
same name; and atomic: no process will perceive an instant when the file
appears not to exist.  I wish I could get the same behavior from IDCAMS
RENAME.

>... This sort
>of thing is considered bad on z/OS. Sure, that's a function of z/OS
>enqueues etc., but JCL is the (relatively) easy to use interface to
>allocation.

On Thu, 12 Jul 2018 09:49:41 +1000, Andrew Rowley wrote:
>
>This works OK except when it doesn't. I recently encountered a problem
>where the command implicitly sourced /etc/profile. Which meant that
>things broke when /etc/profile changed the value of the environment
>variable.
> 
That sounds like a "Don't do that!"  Don't do that.

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

[John McKown]

On Wed, Jul 11, 2018, 14:01 Hobart Spitz  wrote:

> Sorry John.  I know how businesses work.  My comment was rude, sarcastic,
> and uncalled for.  I should not have sent it.
>

Cheerfully accepted. Compared to what a person said to me on a Per language
"newbies" forum, your reply was, at most, chiding.


> 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 11, 2018 at 2:48 PM, John McKown  >
> wrote:
>
> > On Wed, Jul 11, 2018 at 1:38 PM Hobart Spitz  wrote:
> >
> > > John;  So the production schedules set policy in your shop.  Do they
> pay
> > > the bills too?
> > >
> >
> > ​Well, they run the jobs which keep the company running which pays my
> > salary. But if you want who, at least in the past, sets policy -- it was
> > the end user departments. They demand, we supply. The most precious
> > employees are the sales agents. No sales, no money. No money, no company.
> > It runs down hill from there. I.e. the departments support the sales
> force.
> > We support the departments. So we are at the bottom of the support list.
> ​
> >
> > --
> > 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
> >
>
> --
> 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: Using JCL Symbld and TYPRUN=SCAN

[Andrew Rowley]

On 12/07/2018 3:22 AM, John McKown wrote:

​I've seen a lot of UNIX programs which implement the same concept using
shell environment variables. Simple, universal almost, examples are
${HOME}, ${TMPDIR} (and variants), ${CLASSPATH} for Javca, ${PATH}​ for an
//STEPLIB equivalent.

I have a PERL script which implements this. When run, you can specify the
"database name" (PostgreSQL) using --dbname= on the command. If not
specified, it will look for the DBNAME environment variable. If neither,
then it takes a default.
This works OK except when it doesn't. I recently encountered a problem 
where the command implicitly sourced /etc/profile. Which meant that 
things broke when /etc/profile changed the value of the environment 
variable.


--
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: Using JCL Symbld and TYPRUN=SCAN

[Andrew Rowley]

On 12/07/2018 12:51 AM, Hobart Spitz wrote:

It may take a little more skill and experience to write in a real scripting
language than in JCL, but it should be done.
Here is an example of something that is simple in JCL, but very 
difficult to get right in a scripting language (i.e. 6 equivalent scripts):


//JOB1    JOB
//S1  EXEC PGM=PROGRAMA
//DD1 DD DSN=DATASET.A,DISP=SHR
//DD2 DD DSN=DATASET.B,DISP=SHR

//JOB2    JOB
//S1  EXEC PGM=PROGRAMB
//DD1 DD DSN=DATASET.A,DISP=OLD
//DD2 DD DSN=DATASET.B,DISP=SHR

//JOB3    JOB
//S1  EXEC PGM=PROGRAMC
//DD1 DD DSN=DATASET.A,DISP=SHR
//DD2 DD DSN=DATASET.B,DISP=OLD

//JOB4    JOB
//S1  EXEC PGM=PROGRAMD
//DD1 DD DSN=DATASET.A,DISP=OLD
//DD2 DD DSN=DATASET.B,DISP=OLD

//JOB5    JOB
//S1  EXEC PGM=PROGRAME
//DD1 DD DSN=DATASET.A,DISP=SHR

//JOB6    JOB
//S1  EXEC PGM=PROGRAMF
//DD2 DD DSN=DATASET.B,DISP=SHR

I have debugged problems on unix where (unattended) overnight backups 
never completed because 2 jobs deadlocked and just sat there for hours. 
Jobs that do dynamic allocation with anything other than DISP=SHR can't 
be trusted, particularly if they are 3rd party programs where you don't 
know exactly what will be allocated and under what circumstances.


I haven't seen large amounts of batch processing on platforms other than 
z/OS. I suspect a big reason is that without JCL it is impractical. A 
reasonably common message from tar on unix systems is "file changed as 
we read it". I know how to fix the equivalent with z/OS datasets. How do 
you prevent it on Unix? And tar is probably an unusual case,  in that it 
notices and reports when it happens.


The reality seems to be that on other platforms everything is shared, 
and if you are concerned about simultaneous updates (or even 
guaranteeing that a file isn't changed while you read it) it is up to 
everyone accessing that file to cooperate with some form of locking. 
Difficult, if you didn't write all the programs.


On a unix system, you can open a file for writing and another process 
can delete it while you have it open and create a new file with the same 
name. The file you are writing disappears when you close it. This sort 
of thing is considered bad on z/OS. Sure, that's a function of z/OS 
enqueues etc., but JCL is the (relatively) easy to use interface to 
allocation.


--
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: Using JCL Symbld and TYPRUN=SCAN

[Pew, Curtis G]

On Jul 11, 2018, at 5:47 PM, Ed Jaffe  wrote:
> 
> I disagree. BASIC has iterations ('for' loops), forward and backward 
> branching, and subroutine call/return. These fundamental programming language 
> constructs are missing from JCL. This is why it's such a bad programming 
> language.

I don’t think it’s true that JCL is the worst programming language (with all 
due respect to Fred Brooks) because it isn’t really a programming language. 
Should it have been a programming language? Almost certainly, as shown by Unix 
scripting languages. But it isn’t, and although JCL does have many other 
deficiencies, it’s biggest problem is that people come to it expecting a 
programming language, and that’s not what it is.

When I try to explain JCL, I describe it as a human-interface language for an 
obsolete input technology (punch cards) that was thrown together at the last 
minute rather than designed and exposes technical details you’d rather not have 
to know about, but other than that it’s great! An EXEC statement is like 
double-clicking on an app icon, DD statements are like open/save dialogs, etc. 
But it’s not programming.


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


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

Re: Using JCL Symbld and TYPRUN=SCAN

[Ed Jaffe]

On 7/11/2018 3:16 PM, Paul Gilmartin wrote:


So of you search far enough, you can find something worse than JCL to
compare it to, making JCL only the *second* worst programming
language in existence.  Provided BASIC is still viable; otherwise JCL
reclaims last place.


I disagree. BASIC has iterations ('for' loops), forward and backward 
branching, and subroutine call/return. These fundamental programming 
language constructs are missing from JCL. This is why it's such a bad 
programming language.


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


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

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

Re: Deleting all members of a PDS

[Jesse 1 Robinson]

Thanks Kolusu. That does the trick!

.
.
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 Sri h Kolusu
Sent: Wednesday, July 11, 2018 10:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Deleting all members of a PDS

>>but I'm curious if there's some additional keyword that will ignore 
>>the
SHR enqueues. I have not found anything.

Skip,

You need to use FILE keyword on IDCAMS delete like shown below

//DELALL   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//PDS  DD DISP=SHR,DSN=Your.PDS
//SYSINDD *
  DELETE 'Your.PDS(*)' FILE(PDS)
/*

Thanks,
Kolusu


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

Re: Using JCL Symbld and TYPRUN=SCAN

[Paul Gilmartin]

On Wed, 11 Jul 2018 09:56:26 -0700, Tom Brennan wrote:

>I've always considered DD's one of the major differences between MVS and
>other platforms.  I remember one of my first BASIC programs in college
>where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1"
>and sort.  The first thing I thought of was, "So we have to update the
>program every time we want to sort a different file?"
> 
So of you search far enough, you can find something worse than JCL to
compare it to, making JCL only the *second* worst programming
language in existence.  Provided BASIC is still viable; otherwise JCL
reclaims last place.

But don't you have to update the JCL every time you want to sort a different
file?"  Code is code.  I have a number of scripts with symbol assignments at
the top.  I EDIT; SUBMIT; CANCEL.  Why should it be better to edit a JCLLIB
member; SAVE; and INCLUDE it instead?

>DD redirection:  Genius, whoever thought of it.

-- gil

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

Re: Overrides (was: REXX as JCL replacement)

[Clifford McNeill]

The syntax using stepname (not procstep name) is used because there is no 
nested procedure in that refer back.  By that I mean, the reference is not to a 
DD within a proc invoked by the procedure.  That is how I've always viewed it.  
I reread the JCL manual concerning backward references and it does not make 
that clear.  But it does say


*.stepname.ddname Asks the system to copy the data set name from DD statement, 
ddname, in an earlier step, stepname, in the same job.
*.stepname.procstepname.ddname Asks the system to copy the data set name from a 
DD statement in a cataloged or in-stream procedure. Stepname is the name of 
this job step or an earlier job step that calls the procedure, procstepname is 
the name of the procedure step that contains the DD statement, and ddname is 
the name of the DD statement.


>From which I imply that if you invoke a proc and want to refer to/override a 
>DD in that proc, you need to add procstep name to your reference, else its any 
>DD in the same job.  JCL in the job that invokes the proc would need procstep 
>name.  JCL within the proc would not.  How many levels of nesting would that 
>remain true?  I suspect just the one.  I did not have much success having a 
>proc invoke a proc and try to override, in Job JCL or within the first proc, 
>DD statements in the nested proc.


Cliff





>The proc author probably wouldn't do in that manner.  Look at excerpt below, 
>notice how LKED SYSLIN is referencing a dsn from a previous step?
>
>SYS1.PROCLIB(IBMZCPLG) - 01.01  Columns 
> ===>  Scroll ==
>//*
>//* PRE-LINK-EDIT STEP
>//*
>//PLKEDEXEC PGM=EDCPRLK,COND=(8,LT,PLI)
>//...
>//SYSMOD   DD  DSN=&PLNK,DISP=(,PASS),UNIT=SYSALLDA,SPACE=(CYL,(1,1)),
>// DCB=(RECFM=FB,LRECL=80,BLKSIZE=)
>//*
>//* LINK-EDIT STEP
>//*
>//LKED EXEC PGM=IEWL,PARM='XREF',COND=((8,LT,PLI),(8,LE,PLKED))
>//...
>//SYSLIN   DD  DSN=*.PLKED.SYSMOD,DISP=(OLD,DELETE)
>
Suppose the end user calls this with:
//FOOBAR  EXEC  PROC=IBMZXPLG,...

Doesn't the referback need to cite the job step, as in:
//SYSLIN   DD  DSN=*.FOOBAR.PLKED.SYSMOD,DISP=(OLD,DELETE)

... but the author of the PROC can't know a priori the callers jobstep name.

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

[Paul Gilmartin]

On Wed, 11 Jul 2018 22:45:38 +0200, ITschak Mugzach wrote:

>BTW, I wrote a rexx interpreter of JCL a year ago. ITs so easy because JCL
>has a name token format, almost nothing is positional. 
>
Parameters on JOB?
Parameters on EXEC?
Subparameters of DCB, LABEL, ...?
(Well, you said "almost".)

> ...  You miss an IF before the first exec? insert a dummy EXEC
>PGM-IEFBR14. Does nothing and allows the IF.
>
Why should such mickeymouse be necessary?

Why shoudn't IF just behave intuitively, governing everything between
THEN and ELSE/ENDIF?

Why does it not issue at least warnings on use of unsupported/deprecated
constructs?

I  consider this splendid evidence of "What's wrong with JCL?"  And it's
a new feature, hardly primeval.

How did this ever pass design review?

-- gil

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

Broadcom to buy CA?

[Edward Finnell]

https://www.barrons.com/articles/broadcom-tanks-on-report-itll-buy-ca-1531341964?mod=hp_RTA


Stranger in a strange land?

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

[R.S.]

W dniu 2018-07-11 o 20:07, Tom Marchant pisze:

On Wed, 11 Jul 2018 18:06:59 +0200, Tomasz Rola wrote:


BTW, would it count as a mainframe if I ran one inside emulator on PC?

Sure, if you can emulate 170 processors, 32 TB of main memory, 320 FICON 
channels, and robust error handling.

There is much more to a mainframe than the instruction set.

Take care, current PC servers can have more memory than mainframe. It 
have been true for at least 10-15 years.
Current PC do support 32Gbps FC and 40Gbps or 100Gbps LAN NIC. How many? 
Enough.
I can't tell current processor limits, but it is at least half of 
mainframe.
Last, but not least: such PC server beast cost still much less than 
mainframe.

Who cares? Managers.


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

[Tom Marchant]

On Wed, 11 Jul 2018 17:29:28 +, Seymour J Metz wrote:

>Do you have a link to the WFL reference?

I posted it yesterday.
https://public.support.unisys.com/aseries/docs/ClearPath-MCP-18.0/86001047-516

-- 
Tom Marchant

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

Re: NVAS admin panel issue

[saurabh khandelwal]

Hello Alan,

As I am new  to NVAS, can you please suggest how my user id can be defined
as NVAS administrator.

On Wed, Jul 11, 2018 at 10:13 AM, Alan(GMAIL)Watthey 
wrote:

> Saurabh,
>
> As you were already told on the Netview forum, you need to be defined as
> an NVAS Administrator.  Your userid is obviously not.  However, you can
> instead update the settings in batch and then restart NVAS.
>
> Regards,
> Alan Watthey
>
> -Original Message-
> From: saurabh khandelwal [mailto:sourabhkhandelwal...@gmail.com]
> Sent: 10 July 2018 6:04 pm
> Subject: NVAS admin panel issue
>
> Hello Group,
>
>
> We getting below message frequently on our syslog
>
>
> EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453
>
> EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453
>
> EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXMAP  RC=1453
>
> EMS0675E VTAM INQUIRE FAILED FOR LU=A1OXCICS RC=1453
>
>
> I would like to remove these message and for doing this I logged into NVAS
> but i m unable to get admin panel. . I just get parameter panel with adm
> command but I am unable to get the panel to delete these LU.
>
>
> when I type adm on main nvas screen , I get Maintain user parameters
> screen. I am unable to get this admin screen where i can use option 4 to
> delete these unwanted LU.
>
>
>
>
>
> EMSPU1 Maintain User Parameters
>
>
>  sp;  GR Name :
> Terminal: A01IP449
>
> Application . . . ACB Name:  User . .:
> AS54
>
> Last Update  . .: Group. .:
> CRTGRP2
>
>& nbsp;
>  Default Group: Y
>
> Fill in or change the following:
>
>
>   Selection ID  . . . . . __   (1-99) Default Application _  (Y/N)
> ;
>
>   Msg. Received Indicator _(N=Normal/J=Jump/I=
> Information)
>
>   Jump Key  . . . . . . .  (PFnn/PAnn/ATTN)
>
>
>   Logon Profile . . . . . _(U=User/G=Group/S=System)
> p;
>
>   Active Profile  . . . . _(1/2) If User Profile
>
>
>   Profile 1 Comment . . . ___   Profile 2 Comment
> ___
>
>   Application ID Display  _(Y=Yes/N=No)
>
>
>
>
>
> Variables for Logon profile:
>  ;
>
>. . .    . .    . .
> 
>
>. .    . .    . .
> 
>
>. . .. . .. .
> .
>
>
>
>
> Enter a command: d (display), u (update), or l (list).
>
>
>
>
> Can anybody help me to remove these EMS0675E  message from NVAS
>
> --
> 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
>



-- 
Thanks & Regards
Saurabh Khandelwal

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

[ITschak Mugzach]

BTW, I wrote a rexx interpreter of JCL a year ago. ITs so easy because JCL
has a name token format, almost nothing is positional. The aim was
verifying security readiness of JCL, just like the JCL checkers but with
security in mind. so migration is not a problem, but as others said, why
migrate something that most time performs to something that sometimes
performs? You miss an IF before the first exec? insert a dummy EXEC
PGM-IEFBR14. Does nothing and allows the IF.

ITschak

On Wed, Jul 11, 2018 at 10:39 PM ITschak Mugzach  wrote:

> Yap. google "Work Flow Language (WFL) Programming Reference Manual pdf" to
> get the PDF version. Just performing a pentest for a UNISYS client in
> Europe and every-time i am surprised with the agility of it.
>
> ITschak
>
> On Wed, Jul 11, 2018 at 7:29 PM Seymour J Metz  wrote:
>
>> Do you have a link to the WFL reference?
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf
>> of ITschak Mugzach 
>> Sent: Wednesday, July 11, 2018 6:20 AM
>> To: IBM-MAIN@listserv.ua.edu
>> Subject: Re: REXX as JCL replacement
>>
>> Speaking of replacing JCL, how about unisys WFL? It's a programming
>> language dedicated to job flows. BTW, I am happy with jcl...
>>
>> ITschak
>>
>> On Wed, Jul 11, 2018 at 12:09 PM Tony Thigpen  wrote:
>>
>> > So where does JOL get all the other informatoin for the DD card? Is
>> > there some back-end database that has information for all the files that
>> > may be used?
>> >
>> > Tony Thigpen
>> >
>> > Clem Clarke wrote on 07/10/2018 08:33 PM:
>> > > Below is an example of Jol, and the equivalent JCL.
>> > >
>> > > Clem
>> > >
>> > > Simplified Jol Scripting Language for Z/OS, TSO, Linux and Windows
>> > >
>> > > Payroll: Job class C 1000 k;
>> > > Exec Validate Input.Trans, Trans.Action(+1); /* Validate Transations
>> */
>> > > if Validate=0
>> > > then do;
>> > >  Sort transaction(+1) to Sorted.Trans.Actions(+1)
>> > >  Fields(10,10,CH,A);
>> > >  Exec Update Payroll.Master(0), Sorted.Trans.Action(+1),
>> > >  Payroll.Master(+1);
>> > >  If Update = 0
>> > >  then do;
>> > >  Catalog Payroll.Master(+1), Sorted.Trans.Action(+1);
>> > >  Submit Job2;
>> > >  end;
>> > > end;
>> > > else Stop 'Error in PAYROLL Job';
>> > >
>> > >
>> > > 
>> > >
>> > > Equivalent Existing Job Control Language
>> > >
>> > >
>> > > //PAYROLL   JOB  CLASS=C,REGION=1000K
>> > > //VALIDATE   EXEC PGM=VALIDATE
>> > > //SYSPRINT   DD   SYSOUT=*
>> > > //INTRANSDD   DSN=INPUT.TRANS,DISP=SHR
>> > > //OUTTRANS   DD   DSN=TRANS.ACTIONS(+1),DISP=(NEW,PASS),
>> > > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
>> > > //SPACE=(CYL,(10,10),RLSE),
>> > > //UNIT=SYSDA,VOL=SER=WORK01
>> > > //SORT   EXEC PGM=SORT,COND=(VALIDATE,NE,0)
>> > > //SYSOUT DD   SYSOUT=*
>> > > //SORTWK01   DD   UNIT=SYSDA,SPACE=(CYL,20)
>> > > //SORTWK02   DD   UNIT=SYSDA,SPACE=(CYL,20)
>> > > //SORTWK03   DD   UNIT=SYSDA,SPACE=(CYL,20)
>> > > //SORTIN DD   DSN=TRANS.ACTIONS(+1),DISP=(SHR,PASS)
>> > > //SORTOUTDD   DSN=SORTED.TRANS.ACTIONS(+1),
>> > > //DISP=(NEW,PASS),
>> > > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
>> > > //SPACE=(CYL,(10,10),RLSE),
>> > > //UNIT=SYSDA,VOL=SER=WORK01
>> > > //SYSIN  DD   *
>> > >  SORT FIELDS=(10,10,CH,A)
>> > > //UPDATE EXEC PGM=UPDATE,COND=(VALIDATE,NE,0)
>> > > //SYSPRINT   DD   SYSOUT=*
>> > > //MASTIN DD   DSN=PAYROLL.MASTER(0),DISP=SHR
>> > > //TRANS  DD   DSN=TRANS.ACTION(+1),DISP=(SHR,PASS)
>> > > //MASTOUTDD   DSN=PAYROLL.MASTER(+1),DISP=(NEW,PASS),
>> > > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
>> > > //SPACE=(CYL,(10,10),RLSE),
>> > > //UNIT=SYSDA,VOL=SER=WORK01
>> > > //CATLG  EXEC PGM=IEFBR14,COND=(UPDATE,NE,0)
>> > > //DUMMY1 DD   DSN=PAYROLL.MASTER(+1),DISP=(SHR,CATLG)
>> > > //DUMMY2 DD   DSN=SORTED.TRANS.ACTIONS(+1),
>> > > //DISP=(SHR,CATLG)
>> > > //SUBMIT EXEC PGM=IEBGENER,COND=(UPDATE,NE,0)
>> > > //SYSPRINT   DD   SYSOUT=*
>> > > //SYSUT1 DD   DSN=SUBMIT.LIBRARY(JOB2),DISP=SHR
>> > > //SYSUT2 DD   SYSOUT=(*,INTRDR)
>> > > //SYSIN  DD   DUMMY
>> > > //ERRMSG EXEC PGM=SHOWERR,COND=(VALIDATE,EQ,0),
>> > > //   PARM='Error in PAYROLL Job'
>> > >
>> > >
>> > >
>> > > 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 

Re: REXX as JCL replacement

[Jim Mulder]

  There is a GDGBIAS=JOB | STEP   parm on the JOB statement in z/OS 
2.3. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

"IBM Mainframe Discussion List"  wrote on 
07/11/2018 03:35:00 PM:

> From: "Tony Thigpen" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 07/11/2018 04:39 PM
> Subject: Re: REXX as JCL replacement
> Sent by: "IBM Mainframe Discussion List" 
> 
> Restarts with GDGs is one thing z/VSE is much better at. Once a GDG is 
> created in a step, it becomes the current GDG for all following steps. 
> So, following steps don't need to reference +1, then require a change 
> during a restart.
> 
> It part of the difference that z/OS reads the whole job in then 
> allocates everything where as z/VSE only reads the following JCL after 
> the previous step has completed.
> 
> Tony Thigpen
> 
> John McKown wrote on 07/11/2018 01:30 PM:
> > On Wed, Jul 11, 2018 at 12:01 PM Jesse 1 Robinson 

> > wrote:
> > 
> > I, like many here, am old enough to remember how much of a PITA
> > it was to restart a job when a step failed for some reason. Mainly 
deleting
> > datasets, but also changing GDG relative generation numbers if the 
restart
> > is after the step which created the new GDG which is used in 
subsequent
> > steps. {shudder}​



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

Re: [EXTERNAL] Re: Deleting all members of a PDS

[John Eells]

What Sri Hari suggested will do that, too.  I would guess that both of 
them just use STOW ,,I to re-initialize the directory.



Dyck, Lionel B. , RavenTek wrote:

I don't know if this has been suggested but using StarTools or the PDS (cbt 
file 182) command:

FIXPDS RESET

Will both delete all members and reset the PDS so it doesn't need to be 
compressed.

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Scott Barry
Sent: Wednesday, July 11, 2018 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Deleting all members of a PDS

On Wed, 11 Jul 2018 10:43:42 -0700, Sri h Kolusu  wrote:


but I'm curious if there's some additional keyword that will ignore the

SHR enqueues. I have not found anything.

Skip,

You need to use FILE keyword on IDCAMS delete like shown below

//DELALL   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//PDS  DD DISP=SHR,DSN=Your.PDS
//SYSINDD *
  DELETE 'Your.PDS(*)' FILE(PDS)
/*

Thanks,
Kolusu




With the use of "splat" and "delete all members" request, sadly the IDC0553I message doesn't 
provide a list of the members deleted, instead only mention "ALL MEMBERS IN DATA SET  
DELETED".

Now no Auditor-type would go for that -- heck, I even would appreciate knowing 
what I just deleted !!

Still like the enhanced functionality permitting various DSN-mask 
specifications, similar to TSO/ISPF DSLIST (option 3.4).


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: REXX as JCL replacement

[ITschak Mugzach]

Yap. google "Work Flow Language (WFL) Programming Reference Manual pdf" to
get the PDF version. Just performing a pentest for a UNISYS client in
Europe and every-time i am surprised with the agility of it.

ITschak

On Wed, Jul 11, 2018 at 7:29 PM Seymour J Metz  wrote:

> Do you have a link to the WFL reference?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of ITschak Mugzach 
> Sent: Wednesday, July 11, 2018 6:20 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: REXX as JCL replacement
>
> Speaking of replacing JCL, how about unisys WFL? It's a programming
> language dedicated to job flows. BTW, I am happy with jcl...
>
> ITschak
>
> On Wed, Jul 11, 2018 at 12:09 PM Tony Thigpen  wrote:
>
> > So where does JOL get all the other informatoin for the DD card? Is
> > there some back-end database that has information for all the files that
> > may be used?
> >
> > Tony Thigpen
> >
> > Clem Clarke wrote on 07/10/2018 08:33 PM:
> > > Below is an example of Jol, and the equivalent JCL.
> > >
> > > Clem
> > >
> > > Simplified Jol Scripting Language for Z/OS, TSO, Linux and Windows
> > >
> > > Payroll: Job class C 1000 k;
> > > Exec Validate Input.Trans, Trans.Action(+1); /* Validate Transations */
> > > if Validate=0
> > > then do;
> > >  Sort transaction(+1) to Sorted.Trans.Actions(+1)
> > >  Fields(10,10,CH,A);
> > >  Exec Update Payroll.Master(0), Sorted.Trans.Action(+1),
> > >  Payroll.Master(+1);
> > >  If Update = 0
> > >  then do;
> > >  Catalog Payroll.Master(+1), Sorted.Trans.Action(+1);
> > >  Submit Job2;
> > >  end;
> > > end;
> > > else Stop 'Error in PAYROLL Job';
> > >
> > >
> > > 
> > >
> > > Equivalent Existing Job Control Language
> > >
> > >
> > > //PAYROLL   JOB  CLASS=C,REGION=1000K
> > > //VALIDATE   EXEC PGM=VALIDATE
> > > //SYSPRINT   DD   SYSOUT=*
> > > //INTRANSDD   DSN=INPUT.TRANS,DISP=SHR
> > > //OUTTRANS   DD   DSN=TRANS.ACTIONS(+1),DISP=(NEW,PASS),
> > > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
> > > //SPACE=(CYL,(10,10),RLSE),
> > > //UNIT=SYSDA,VOL=SER=WORK01
> > > //SORT   EXEC PGM=SORT,COND=(VALIDATE,NE,0)
> > > //SYSOUT DD   SYSOUT=*
> > > //SORTWK01   DD   UNIT=SYSDA,SPACE=(CYL,20)
> > > //SORTWK02   DD   UNIT=SYSDA,SPACE=(CYL,20)
> > > //SORTWK03   DD   UNIT=SYSDA,SPACE=(CYL,20)
> > > //SORTIN DD   DSN=TRANS.ACTIONS(+1),DISP=(SHR,PASS)
> > > //SORTOUTDD   DSN=SORTED.TRANS.ACTIONS(+1),
> > > //DISP=(NEW,PASS),
> > > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
> > > //SPACE=(CYL,(10,10),RLSE),
> > > //UNIT=SYSDA,VOL=SER=WORK01
> > > //SYSIN  DD   *
> > >  SORT FIELDS=(10,10,CH,A)
> > > //UPDATE EXEC PGM=UPDATE,COND=(VALIDATE,NE,0)
> > > //SYSPRINT   DD   SYSOUT=*
> > > //MASTIN DD   DSN=PAYROLL.MASTER(0),DISP=SHR
> > > //TRANS  DD   DSN=TRANS.ACTION(+1),DISP=(SHR,PASS)
> > > //MASTOUTDD   DSN=PAYROLL.MASTER(+1),DISP=(NEW,PASS),
> > > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
> > > //SPACE=(CYL,(10,10),RLSE),
> > > //UNIT=SYSDA,VOL=SER=WORK01
> > > //CATLG  EXEC PGM=IEFBR14,COND=(UPDATE,NE,0)
> > > //DUMMY1 DD   DSN=PAYROLL.MASTER(+1),DISP=(SHR,CATLG)
> > > //DUMMY2 DD   DSN=SORTED.TRANS.ACTIONS(+1),
> > > //DISP=(SHR,CATLG)
> > > //SUBMIT EXEC PGM=IEBGENER,COND=(UPDATE,NE,0)
> > > //SYSPRINT   DD   SYSOUT=*
> > > //SYSUT1 DD   DSN=SUBMIT.LIBRARY(JOB2),DISP=SHR
> > > //SYSUT2 DD   SYSOUT=(*,INTRDR)
> > > //SYSIN  DD   DUMMY
> > > //ERRMSG EXEC PGM=SHOWERR,COND=(VALIDATE,EQ,0),
> > > //   PARM='Error in PAYROLL Job'
> > >
> > >
> > >
> > > 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.
> > >>
> > >> 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.
> > >>
> > >> 

Re: Seeking a tool to do a network security scan of z/OS

[ITschak Mugzach]

Do you mean outside of the mainframe? Not as a single package, but NMAP
will show you which ports are opened on the mainframe. If your mainframe
answers the scan, you already have a problem... Now assume that port 25 is
open and your mail server is configured an MTA. One can connect to the
server with HELLO call and send emails under fake name and domain as spam
to collect userids, passwords and other secrets.

It's a good idea to have an extra agent to IronSphere to do that -)

ITschak

On Wed, Jul 11, 2018 at 9:53 PM Dyck, Lionel B. (RavenTek) <
lionel.d...@va.gov> wrote:

> Is there a tool available that can do a network security scan of a z/OS
> system to identify network vulnerabilities?
>
> thanks
>
> --
> Lionel B. Dyck (Contractor)  <
> Mainframe Systems Programmer - RavenTek Solution Partners
>
>
>
> --
> 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: Overrides (was: REXX as JCL replacement)

[Farley, Peter x23353]

Paul,

No, the PROC referback does NOT need to know the step name that invoked the 
PROC.  It is the nearest prior procstepname that is referenced, so multiple 
compile PROC executions in the same job work just fine and refer to the correct 
dataset.

AFAIK , that's been the case since PROC's were first introduced.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, July 11, 2018 3:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overrides (was: REXX as JCL replacement)

On Wed, 11 Jul 2018 19:30:16 +, Clifford McNeill wrote:

>The proc author probably wouldn't do in that manner.  Look at excerpt below, 
>notice how LKED SYSLIN is referencing a dsn from a previous step?
>
>SYS1.PROCLIB(IBMZCPLG) - 01.01  Columns 
> ===>  Scroll ==
>//*
>//* PRE-LINK-EDIT STEP
>//*
>//PLKEDEXEC PGM=EDCPRLK,COND=(8,LT,PLI)
>//...
>//SYSMOD   DD  DSN=&PLNK,DISP=(,PASS),UNIT=SYSALLDA,SPACE=(CYL,(1,1)),
>// DCB=(RECFM=FB,LRECL=80,BLKSIZE=)
>//*
>//* LINK-EDIT STEP
>//*
>//LKED EXEC PGM=IEWL,PARM='XREF',COND=((8,LT,PLI),(8,LE,PLKED))
>//...
>//SYSLIN   DD  DSN=*.PLKED.SYSMOD,DISP=(OLD,DELETE)
> 
Suppose the end user calls this with:
//FOOBAR  EXEC  PROC=IBMZXPLG,...

Doesn't the referback need to cite the job step, as in:
//SYSLIN   DD  DSN=*.FOOBAR.PLKED.SYSMOD,DISP=(OLD,DELETE)

... but the author of the PROC can't know a priori the callers jobstep name.

--


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

Seeking a tool to do a network security scan of z/OS

[Dyck, Lionel B. (RavenTek)]

Is there a tool available that can do a network security scan of a z/OS system 
to identify network vulnerabilities?

thanks

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer - RavenTek Solution Partners



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

Re: Overrides (was: REXX as JCL replacement)

[Paul Gilmartin]

On Wed, 11 Jul 2018 19:30:16 +, Clifford McNeill wrote:

>The proc author probably wouldn't do in that manner.  Look at excerpt below, 
>notice how LKED SYSLIN is referencing a dsn from a previous step?
>
>SYS1.PROCLIB(IBMZCPLG) - 01.01  Columns 
> ===>  Scroll ==
>//*
>//* PRE-LINK-EDIT STEP
>//*
>//PLKEDEXEC PGM=EDCPRLK,COND=(8,LT,PLI)
>//...
>//SYSMOD   DD  DSN=&PLNK,DISP=(,PASS),UNIT=SYSALLDA,SPACE=(CYL,(1,1)),
>// DCB=(RECFM=FB,LRECL=80,BLKSIZE=)
>//*
>//* LINK-EDIT STEP
>//*
>//LKED EXEC PGM=IEWL,PARM='XREF',COND=((8,LT,PLI),(8,LE,PLKED))
>//...
>//SYSLIN   DD  DSN=*.PLKED.SYSMOD,DISP=(OLD,DELETE)
> 
Suppose the end user calls this with:
//FOOBAR  EXEC  PROC=IBMZXPLG,...

Doesn't the referback need to cite the job step, as in:
//SYSLIN   DD  DSN=*.FOOBAR.PLKED.SYSMOD,DISP=(OLD,DELETE)

... but the author of the PROC can't know a priori the callers jobstep name.

-- gil

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

Re: Deleting all members of a PDS

[Hobart Spitz]

pipe listpds 'your.pds' | cons | chop 3 | insert /delete 'your.pds' / | tso
| cons

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 11, 2018 at 3:13 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 11 Jul 2018 14:59:15 -0400, Hobart Spitz wrote:
>
> >You're in TSO.  Add this line, or equivalent, before the DELETE.
> >
> >listd 'your.pds' mem
> >
> What about the TOCTTOU hazard?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: REXX as JCL replacement

[Tony Thigpen]

Restarts with GDGs is one thing z/VSE is much better at. Once a GDG is 
created in a step, it becomes the current GDG for all following steps. 
So, following steps don't need to reference +1, then require a change 
during a restart.


It part of the difference that z/OS reads the whole job in then 
allocates everything where as z/VSE only reads the following JCL after 
the previous step has completed.


Tony Thigpen

John McKown wrote on 07/11/2018 01:30 PM:

On Wed, Jul 11, 2018 at 12:01 PM Jesse 1 Robinson 
wrote:

I, like many here, am old enough to remember how much of a PITA
it was to restart a job when a step failed for some reason. Mainly deleting
datasets, but also changing GDG relative generation numbers if the restart
is after the step which created the new GDG which is used in subsequent
steps. {shudder}​


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

Re: Overrides (was: REXX as JCL replacement)

[Clifford McNeill]

The proc author probably wouldn't do in that manner.  Look at excerpt below, 
notice how LKED SYSLIN is referencing a dsn from a previous step?



SYS1.PROCLIB(IBMZCPLG) - 01.01  Columns 
 ===>  Scroll ==
//*
//* PRE-LINK-EDIT STEP
//*
//PLKEDEXEC PGM=EDCPRLK,COND=(8,LT,PLI)
//STEPLIB  DD  DSN=,DISP=SHR
//SYSMSGS  DD  DSN=(),DISP=SHR
//SYSLIB   DD  DUMMY
//SYSMOD   DD  DSN=&,DISP=(,PASS),UNIT=SYSALLDA,SPACE=(CYL,(1,1)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=)
//SYSIN DD DSN=*.PLI.SYSLIN,DISP=(OLD,DELETE)
//SYSPRINT DD  SYSOUT=*
//SYSOUT   DD  SYSOUT=*
//*
//* LINK-EDIT STEP
//*
//LKED EXEC PGM=IEWL,PARM='XREF',COND=((8,LT,PLI),(8,LE,PLKED))
//SYSLIB   DD  DSN=,DISP=SHR
//SYSPRINT DD  SYSOUT=*
//SYSLIN   DD  DSN=*.PLKED.SYSMOD,DISP=(OLD,DELETE)


Cliff McNeill


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, July 11, 2018 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Overrides (was: REXX as JCL replacement)

On Wed, 11 Jul 2018 10:35:08 -0700, Lizette Koehler wrote:

>I would include the caveat
>
>Even though it is available, do not use Nested procs.  Trying to override a 
>proc within a proc within a proc ..   rarely succeeds.
>
I can't decide whether the author of the original RFE overlooked a requirement,
perhaps assuming it was implicit, or IBM shirked the implementation.  There
ougnt to be an extended syntax, such as:
//refdd  DD  sysxxx=*.jobstep.procstep.subprocstep.subsub ... .ddname

BTW, what's the syntax by which a procstep can refer to a data set passed from
an earlier procstep?  Such as

//MAKE  PROC
//C EXEC  PGM=COMPILER,...
//SYSPUNCH  DDDISP=(,PASS),
...
//L EXEC  PGM=IEWL
//SYSLINDDDISP=(OLD,PASS),DSN=*..C.SYSPUNCH

It seems the author of the PROC needs to know, but can't know, the
user's job step name to code as the .

What am I missing?

-- gil

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

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

Re: REXX as JCL replacement

[Paul Gilmartin]

On Wed, 11 Jul 2018 14:09:16 -0500, Tom Marchant wrote:
>>
>>>I don't like JCL, but I don't see any way forward other than incremental 
>>>improvements.
>>>
>>Business case for those?  And trimming the whiskers from JCL would
>>create compatibility problems for users who have come to depend on
>>them, even if only as circumventions.
>
>An example of an incremental improvement is IF/THEN/ELSE/ENDIF.
> 
If only the developers had been conscientious:
//NAME  JOB   ...
//*  "IF" *should* not occur before the first EXEC.  Accepted with no 
warning.
//MAYBE IFFALSE THEN   /* Unsupported syntax, accepted with no 
warning!  */
//STEP1 EXEC  PGM=IEFBR14  /* This step is executed, but ...*/
//STEP2 EXEC  PGM=IEFBR14  /* ... this step is skipped.  WTF!?  */
//MAYBE ENDIF  /* Label *should* be unique.  No warning.  */

... the face of JCL bcomes increasingly unkempt.

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

[Seymour J Metz]

My thinking was that part of the parallel allocation would be to free existing 
allocations, but there might be issues with that.

If there is no business case for an incremental improvement than there 
certainly isn't one for a total replacement. Given the control block structure 
for starting a new address space and allocating its data sets, that would be a 
massive effort.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, July 11, 2018 2:51 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement

On Wed, 11 Jul 2018 18:09:21 +, Seymour J Metz wrote:

>You keep missing the point that REXX does not currently provide the 
>serialization
>that is available through JCL. Rewriting the job as a REXX script that does 
>not do
>the necessary serialization is a CLM.
>
??CLM??

>That's why I suggested a parallel allocation facility usable from REXX.
>
In order to avoid deadlocks, that parallel allocation facility must be invoked
only once, and before any other SYSDSN ENQs are extant.

There might be a way:  launch the Rexx script from Unix System Services.
Better yet, support //SYSEXEC DD PATH='/...' so no static ENQs are needed.
RFE material?

>I don't like JCL, but I don't see any way forward other than incremental 
>improvements.
>
Business case for those?  And trimming the whiskers from JCL would
create compatibility problems for users who have come to depend on
them, even if only as circumventions.

-- gil

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

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

Re: Deleting all members of a PDS

[Paul Gilmartin]

On Wed, 11 Jul 2018 14:59:15 -0400, Hobart Spitz wrote:

>You're in TSO.  Add this line, or equivalent, before the DELETE.
>
>listd 'your.pds' mem
> 
What about the TOCTTOU hazard?

-- gil

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

Overrides (was: REXX as JCL replacement)

[Paul Gilmartin]

On Wed, 11 Jul 2018 10:35:08 -0700, Lizette Koehler wrote:

>I would include the caveat
>
>Even though it is available, do not use Nested procs.  Trying to override a 
>proc within a proc within a proc ..   rarely succeeds.
> 
I can't decide whether the author of the original RFE overlooked a requirement,
perhaps assuming it was implicit, or IBM shirked the implementation.  There
ougnt to be an extended syntax, such as:
//refdd  DD  sysxxx=*.jobstep.procstep.subprocstep.subsub ... .ddname

BTW, what's the syntax by which a procstep can refer to a data set passed from
an earlier procstep?  Such as

//MAKE  PROC
//C EXEC  PGM=COMPILER,...
//SYSPUNCH  DDDISP=(,PASS),
...
//L EXEC  PGM=IEWL
//SYSLINDDDISP=(OLD,PASS),DSN=*..C.SYSPUNCH

It seems the author of the PROC needs to know, but can't know, the
user's job step name to code as the .

What am I missing?

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

[Tom Marchant]

On Wed, 11 Jul 2018 13:51:05 -0500, Paul Gilmartin wrote:

>On Wed, 11 Jul 2018 18:09:21 +, Seymour J Metz wrote:
>
>>I don't like JCL, but I don't see any way forward other than incremental 
>>improvements.
>>
>Business case for those?  And trimming the whiskers from JCL would
>create compatibility problems for users who have come to depend on
>them, even if only as circumventions.


An example of an incremental improvement is IF/THEN/ELSE/ENDIF.

-- 
Tom Marchant

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

[Hobart Spitz]

Sorry John.  I know how businesses work.  My comment was rude, sarcastic,
and uncalled for.  I should not have sent it.

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 11, 2018 at 2:48 PM, John McKown 
wrote:

> On Wed, Jul 11, 2018 at 1:38 PM Hobart Spitz  wrote:
>
> > John;  So the production schedules set policy in your shop.  Do they pay
> > the bills too?
> >
>
> ​Well, they run the jobs which keep the company running which pays my
> salary. But if you want who, at least in the past, sets policy -- it was
> the end user departments. They demand, we supply. The most precious
> employees are the sales agents. No sales, no money. No money, no company.
> It runs down hill from there. I.e. the departments support the sales force.
> We support the departments. So we are at the bottom of the support list. ​
>
> --
> 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
>

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

Re: Deleting all members of a PDS

[Hobart Spitz]

You're in TSO.  Add this line, or equivalent, before the DELETE.

listd 'your.pds' mem

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 11, 2018 at 2:56 PM, Scott Barry  wrote:

> On Wed, 11 Jul 2018 10:43:42 -0700, Sri h Kolusu 
> wrote:
>
> >>>but I'm curious if there's some additional keyword that will ignore the
> >SHR enqueues. I have not found anything.
> >
> >Skip,
> >
> >You need to use FILE keyword on IDCAMS delete like shown below
> >
> >//DELALL   EXEC PGM=IDCAMS
> >//SYSPRINT DD SYSOUT=*
> >//PDS  DD DISP=SHR,DSN=Your.PDS
> >//SYSINDD *
> >  DELETE 'Your.PDS(*)' FILE(PDS)
> >/*
> >
> >Thanks,
> >Kolusu
> >
> >
>
> With the use of "splat" and "delete all members" request, sadly the
> IDC0553I message doesn't provide a list of the members deleted, instead
> only mention "ALL MEMBERS IN DATA SET  DELETED".
>
> Now no Auditor-type would go for that -- heck, I even would appreciate
> knowing what I just deleted !!
>
> Still like the enhanced functionality permitting various DSN-mask
> specifications, similar to TSO/ISPF DSLIST (option 3.4).
>
> Scott Barry
> SBBWorks, Inc.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: [EXTERNAL] Re: Deleting all members of a PDS

[Dyck, Lionel B. (RavenTek)]

I don't know if this has been suggested but using StarTools or the PDS (cbt 
file 182) command:

FIXPDS RESET

Will both delete all members and reset the PDS so it doesn't need to be 
compressed.

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Scott Barry
Sent: Wednesday, July 11, 2018 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Deleting all members of a PDS

On Wed, 11 Jul 2018 10:43:42 -0700, Sri h Kolusu  wrote:

>>>but I'm curious if there's some additional keyword that will ignore the
>SHR enqueues. I have not found anything.
>
>Skip,
>
>You need to use FILE keyword on IDCAMS delete like shown below
>
>//DELALL   EXEC PGM=IDCAMS
>//SYSPRINT DD SYSOUT=*
>//PDS  DD DISP=SHR,DSN=Your.PDS
>//SYSINDD *
>  DELETE 'Your.PDS(*)' FILE(PDS)
>/*
>
>Thanks,
>Kolusu
>
>

With the use of "splat" and "delete all members" request, sadly the IDC0553I 
message doesn't provide a list of the members deleted, instead only mention 
"ALL MEMBERS IN DATA SET  DELETED".  

Now no Auditor-type would go for that -- heck, I even would appreciate knowing 
what I just deleted !!

Still like the enhanced functionality permitting various DSN-mask 
specifications, similar to TSO/ISPF DSLIST (option 3.4).

Scott Barry
SBBWorks, Inc.

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

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

Re: Deleting all members of a PDS

[Scott Barry]

On Wed, 11 Jul 2018 10:43:42 -0700, Sri h Kolusu  wrote:

>>>but I'm curious if there's some additional keyword that will ignore the
>SHR enqueues. I have not found anything.
>
>Skip,
>
>You need to use FILE keyword on IDCAMS delete like shown below
>
>//DELALL   EXEC PGM=IDCAMS
>//SYSPRINT DD SYSOUT=*
>//PDS  DD DISP=SHR,DSN=Your.PDS
>//SYSINDD *
>  DELETE 'Your.PDS(*)' FILE(PDS)
>/*
>
>Thanks,
>Kolusu
>
>

With the use of "splat" and "delete all members" request, sadly the IDC0553I 
message doesn't provide a list of the members deleted, instead only mention 
"ALL MEMBERS IN DATA SET  DELETED".  

Now no Auditor-type would go for that -- heck, I even would appreciate knowing 
what I just deleted !!

Still like the enhanced functionality permitting various DSN-mask 
specifications, similar to TSO/ISPF DSLIST (option 3.4).

Scott Barry
SBBWorks, Inc.

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

Re: REXX as JCL replacement

[Paul Gilmartin]

On Wed, 11 Jul 2018 18:09:21 +, Seymour J Metz wrote:

>You keep missing the point that REXX does not currently provide the 
>serialization
>that is available through JCL. Rewriting the job as a REXX script that does 
>not do
>the necessary serialization is a CLM.
>
??CLM??

>That's why I suggested a parallel allocation facility usable from REXX.
>
In order to avoid deadlocks, that parallel allocation facility must be invoked
only once, and before any other SYSDSN ENQs are extant.

There might be a way:  launch the Rexx script from Unix System Services.
Better yet, support //SYSEXEC DD PATH='/...' so no static ENQs are needed.
RFE material?

>I don't like JCL, but I don't see any way forward other than incremental 
>improvements.
>
Business case for those?  And trimming the whiskers from JCL would
create compatibility problems for users who have come to depend on
them, even if only as circumventions.

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

[John McKown]

On Wed, Jul 11, 2018 at 1:38 PM Hobart Spitz  wrote:

> John;  So the production schedules set policy in your shop.  Do they pay
> the bills too?
>

​Well, they run the jobs which keep the company running which pays my
salary. But if you want who, at least in the past, sets policy -- it was
the end user departments. They demand, we supply. The most precious
employees are the sales agents. No sales, no money. No money, no company.
It runs down hill from there. I.e. the departments support the sales force.
We support the departments. So we are at the bottom of the support list. ​

-- 
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: Allocating VSAM in JCL was Re: z/OS JCl vs. VSE JCL: VSAM files

[Longabaugh, Robert E]

I use JCL VSAM for CA Allocate testing

This example was for an in-house program and is from 2005, so 13 years ago 
sounds right.  Obviously KEYLEN and KEYOFF are only needed for RECORG=KS.
//PTFXREF   DD   DISP=(,CATLG,DELETE),DSN=, 
//  STORCLAS=TSO,   
//  LRECL=206,KEYLEN=7,KEYOFF=0,RECORG=KS,  
//  SPACE=(TRK,(10,10)) 


TSO ALLOC can also create VSAM files.  TSO DEFINE would be easier, but 
different syntax.
ALLOC DA('TST.XYZ.LDS') -   
 NEW CATALOG  -  
 TRACKS -
 SPACE(5 5) -
LRECL(4096) -
RECORG(LS) - 
DATACLAS(LDS) -
STORCLAS(SMSLDS) -  
DSNTYPE(EXTREQ) -
DSKEYLBL(TEST.KEY)






-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Wednesday, July 11, 2018 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Allocating VSAM in JCL was Re: z/OS JCl vs. VSE JCL: VSAM files

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


[Default] On 10 Jul 2018 15:33:56 -0700, in bit.listserv.ibm-main 
johnrcl...@gmail.com (John Clifford) wrote:

>it is not the default but is the only correct way to access a vsam file.
>disp=shr,dsn=.vsam (possible bufno,bufni,...etc)
>
>Never disp=new or delete.   Disp=old can be used if you need to make sure
>you are the only one accessing the file but if it is open in CICS it 
>will hang.

As of over 13 years ago, you could allocate a VSAM file in JCL and even a 
temporary one.  I never used the facility but it is there.

Clark Morris
>
>On Tue, Jul 10, 2018 at 6:07 PM, Tony Thigpen  wrote:
>
>> So, DISP=SHR is not the default, as I thought was implied by John's 
>> statement that "Z/os VSAM is always accessed as DISP=SHR."
>>
>> Tony Thigpen
>>
>> Gibney, Dave wrote on 07/10/2018 05:49 PM:
>>
>>> If DISP=SHR (that is if not DISP is provided), then the JCL Default 
>>> of
>>> (NEW,PASS) would happen and the job would fail
>>>
>>> -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen
 Sent: Tuesday, July 10, 2018 2:43 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: z/OS JCl vs. VSE JCL: VSAM files

 Then, why does every VSAM DD for every z/OS site I have worked 
 with, always include DISP=SHR?
 (I guess, because it's a habit from non-VSAM files and nobody told 
 them they did not have to do it.)

 Tony Thigpen

 John Clifford wrote on 07/10/2018 04:16 PM:

> Z/os VSAM is always accessed as  DISP=SHR.
>

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

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

[Hobart Spitz]

John;  So the production schedules set policy in your shop.  Do they pay
the bills too?

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 11, 2018 at 2:09 PM, Seymour J Metz  wrote:

> You keep missing the point that REXX does not currently provide the
> serialization that is available through JCL. Rewriting the job as a REXX
> script that does not do the necessary serialization is a CLM. That's why I
> suggested a parallel allocation facility usable from REXX.
>
> I don't like JCL, but I don't see any way forward other than incremental
> improvements.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Hobart Spitz 
> Sent: Wednesday, July 11, 2018 1:30 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: REXX as JCL replacement
>
> Skip;
>
> What you say is true.  Massive replacement would not be justified.  No one
> is advocating such an effort.
>
> What needs to happen is for people to stop writing new JCL (or copying old
> JCL, especially the bad stuff) and work as if it were the 21st century.
>
> In addition to not writing new JCL, there are some prime replacement
> candidates to consider now:
>
>- PROCs are executed frequently.  The improvements, whether functional
>or performance, would be multiplied across all JOBs that EXECute those
>PROCs.
>-
>- PROCs that only use utilities and/or batch TSO, combining all into one
>step.
>- Replacing frequently executed IEFBR14s that sometimes create a dataset
>just to delete it, or that delete perfectly good dataset.  Are all those
>ENQs, RESERVEs, catalog searches and updates, and VTOC searches and
> updates
>really worth it just because DISP=MOD can't change DCB info?
>- JOBs with complex parameter or restart requirements.
>- JOBs that run frequently.
>- JOBs that need special serialization.  Invoke the program(s) in a REXX
>loop.  Serialization problems gone.
>- Applications that do updates primarily in DB2 and/or PDSEs.
>- Applications that need more generalized automation.  Drop the
>expensive third-party software.  You play by your rules, not someone
> else's.
>- Any process that has complex or hard to maintain JCL.
>
> There are more.
>
> Once you understand the benefits, to vendors and customers, the choice is
> clear.
>
> 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 11, 2018 at 1:00 PM, Jesse 1 Robinson  >
> wrote:
>
> > This thread is entertaining but largely cherry-pie-in-the-sky. While it
> > might be a nice exercise for sysprogs and architects, what's missing so
> far
> > is a compelling business case to justify the pain and agony of actually
> > replacing JCL in a real world environment. For a mature shop with
> thousands
> > of jobs to manage--most of which work very well most of the time--it
> would
> > be a very hard sell to justify resources to build a replacement that
> would
> > mostly work better most of the time.
> >
> > I'm reminded of the old saw about teaching a dog to walk on its hind
> legs.
> > What's compelling is not that the dog does it well but merely that she
> can
> > walk that way at all. Worth maybe admission to a vaudeville show but not
> a
> > reason to turn your life upside down.
> > .
> > .
> > 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 Hobart Spitz
> > Sent: Wednesday, July 11, 2018 9:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: REXX as JCL replacement
> >
> > Gil wrote:
> > >SORT is quasi-batch:
> > A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can
> run
> > SORT(s) to completion completely independently of the main pipe, to name
> > just two possibilities.  The terminology in the PIPElines documentation
> is
> > "delaying records".  Most built-in filters don't delay records, others
> > might delay some records some of the time, and others, like SORT delay,
> of
> > necessity, all records.  Any filter that has to hold on to a record and
> > "think about it" before producing the corresponding result is said to
> > "delay the record".
> >
> > Any sequence of filters, each of which don't delay the record, when
> > combined in 

Re: REXX as JCL replacement

[Seymour J Metz]

You keep missing the point that REXX does not currently provide the 
serialization that is available through JCL. Rewriting the job as a REXX script 
that does not do the necessary serialization is a CLM. That's why I suggested a 
parallel allocation facility usable from REXX.

I don't like JCL, but I don't see any way forward other than incremental 
improvements.


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


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

Skip;

What you say is true.  Massive replacement would not be justified.  No one
is advocating such an effort.

What needs to happen is for people to stop writing new JCL (or copying old
JCL, especially the bad stuff) and work as if it were the 21st century.

In addition to not writing new JCL, there are some prime replacement
candidates to consider now:

   - PROCs are executed frequently.  The improvements, whether functional
   or performance, would be multiplied across all JOBs that EXECute those
   PROCs.
   -
   - PROCs that only use utilities and/or batch TSO, combining all into one
   step.
   - Replacing frequently executed IEFBR14s that sometimes create a dataset
   just to delete it, or that delete perfectly good dataset.  Are all those
   ENQs, RESERVEs, catalog searches and updates, and VTOC searches and updates
   really worth it just because DISP=MOD can't change DCB info?
   - JOBs with complex parameter or restart requirements.
   - JOBs that run frequently.
   - JOBs that need special serialization.  Invoke the program(s) in a REXX
   loop.  Serialization problems gone.
   - Applications that do updates primarily in DB2 and/or PDSEs.
   - Applications that need more generalized automation.  Drop the
   expensive third-party software.  You play by your rules, not someone else's.
   - Any process that has complex or hard to maintain JCL.

There are more.

Once you understand the benefits, to vendors and customers, the choice is
clear.

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 11, 2018 at 1:00 PM, Jesse 1 Robinson 
wrote:

> This thread is entertaining but largely cherry-pie-in-the-sky. While it
> might be a nice exercise for sysprogs and architects, what's missing so far
> is a compelling business case to justify the pain and agony of actually
> replacing JCL in a real world environment. For a mature shop with thousands
> of jobs to manage--most of which work very well most of the time--it would
> be a very hard sell to justify resources to build a replacement that would
> mostly work better most of the time.
>
> I'm reminded of the old saw about teaching a dog to walk on its hind legs.
> What's compelling is not that the dog does it well but merely that she can
> walk that way at all. Worth maybe admission to a vaudeville show but not a
> reason to turn your life upside down.
> .
> .
> 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 Hobart Spitz
> Sent: Wednesday, July 11, 2018 9:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: REXX as JCL replacement
>
> Gil wrote:
> >SORT is quasi-batch:
> A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can run
> SORT(s) to completion completely independently of the main pipe, to name
> just two possibilities.  The terminology in the PIPElines documentation is
> "delaying records".  Most built-in filters don't delay records, others
> might delay some records some of the time, and others, like SORT delay, of
> necessity, all records.  Any filter that has to hold on to a record and
> "think about it" before producing the corresponding result is said to
> "delay the record".
>
> Any sequence of filters, each of which don't delay the record, when
> combined in a single stream, will not delay the record.  So much of the
> time, you don't have or don't care about record delay.
>
> Delaying records doesn't into play until you get into non-trivial
> multiple-stream PIPElines, where you have split a data stream into two and
> then later combine them.  In order for the right records to arrive at the
> desired time at the joining point, you may need to take record delay into
> account.  This is something that is impossible in UNIX (at this time),
> because UNIX piping data flow is not deterministic.
>
> Beginning pipers don't usually run into the issue.  For one, there is so
> much you can do with REXX 

Re: SUSE splits from Microfocus

[Tom Marchant]

On Wed, 11 Jul 2018 18:06:59 +0200, Tomasz Rola wrote:

>BTW, would it count as a mainframe if I ran one inside emulator on PC?

Sure, if you can emulate 170 processors, 32 TB of main memory, 320 FICON 
channels, and robust error handling.

There is much more to a mainframe than the instruction set.

-- 
Tom Marchant

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

Looking for commercial Z processing time

[Charles Mills]

An associate is looking to purchase Z processing time on an ongoing basis
(in other words, not a one-shot conversion or test). It is for a commercial
application so IBM Dallas or a z/PDT is not suitable. The desired
characteristics are

- Current processor: BC12 or above, with a general intention to stay
reasonably current
- Current z/OS: V2R2 or above, with a general intention to stay reasonably
current
- Dedicated LPAR preferred but will consider shared
- About 3 MSUs required on an off-and-on basis
- Ability to configure VPN access
- Enterprise COBOL
- DASD requirement to be specified but would be quite modest
- Legal: No z/OS on Hercules
- It is a stable application with a limited userid requirement so there
should be little in the way of ongoing sysprog activity required

Please respond privately -- don't clutter up IBMMAIN -- to charlesm at mcn
dot org

Charles 

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

Re: Deleting all members of a PDS

[Sri h Kolusu]

>>but I'm curious if there's some additional keyword that will ignore the
SHR enqueues. I have not found anything.

Skip,

You need to use FILE keyword on IDCAMS delete like shown below

//DELALL   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//PDS  DD DISP=SHR,DSN=Your.PDS
//SYSINDD *
  DELETE 'Your.PDS(*)' FILE(PDS)
/*

Thanks,
Kolusu


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

[Lizette Koehler]

I would include the caveat

Even though it is available, do not use Nested procs.  Trying to override a 
proc within a proc within a proc ..   rarely succeeds.

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Hobart Spitz
> Sent: Wednesday, July 11, 2018 10:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REXX as JCL replacement
> 
> Skip;
> 
> What you say is true.  Massive replacement would not be justified.  No one is
> advocating such an effort.
> 
> What needs to happen is for people to stop writing new JCL (or copying old
> JCL, especially the bad stuff) and work as if it were the 21st century.
> 
> In addition to not writing new JCL, there are some prime replacement
> candidates to consider now:
> 
>- PROCs are executed frequently.  The improvements, whether functional
>or performance, would be multiplied across all JOBs that EXECute those
>PROCs.
>-
>- PROCs that only use utilities and/or batch TSO, combining all into one
>step.
>- Replacing frequently executed IEFBR14s that sometimes create a dataset
>just to delete it, or that delete perfectly good dataset.  Are all those
>ENQs, RESERVEs, catalog searches and updates, and VTOC searches and
> updates
>really worth it just because DISP=MOD can't change DCB info?
>- JOBs with complex parameter or restart requirements.
>- JOBs that run frequently.
>- JOBs that need special serialization.  Invoke the program(s) in a REXX
>loop.  Serialization problems gone.
>- Applications that do updates primarily in DB2 and/or PDSEs.
>- Applications that need more generalized automation.  Drop the
>expensive third-party software.  You play by your rules, not someone
> else's.
>- Any process that has complex or hard to maintain JCL.
> 
> There are more.
> 
> Once you understand the benefits, to vendors and customers, the choice is
> clear.
> 
> 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 11, 2018 at 1:00 PM, Jesse 1 Robinson 
> wrote:
> 
> > This thread is entertaining but largely cherry-pie-in-the-sky. While
> > it might be a nice exercise for sysprogs and architects, what's
> > missing so far is a compelling business case to justify the pain and
> > agony of actually replacing JCL in a real world environment. For a
> > mature shop with thousands of jobs to manage--most of which work very
> > well most of the time--it would be a very hard sell to justify
> > resources to build a replacement that would mostly work better most of the
> time.
> >
> > I'm reminded of the old saw about teaching a dog to walk on its hind legs.
> > What's compelling is not that the dog does it well but merely that she
> > can walk that way at all. Worth maybe admission to a vaudeville show
> > but not a reason to turn your life upside down.
> > .
> > .
> > 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 Hobart Spitz
> > Sent: Wednesday, July 11, 2018 9:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: REXX as JCL replacement
> >
> > Gil wrote:
> > >SORT is quasi-batch:
> > A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can
> > run
> > SORT(s) to completion completely independently of the main pipe, to
> > name just two possibilities.  The terminology in the PIPElines
> > documentation is "delaying records".  Most built-in filters don't
> > delay records, others might delay some records some of the time, and
> > others, like SORT delay, of necessity, all records.  Any filter that
> > has to hold on to a record and "think about it" before producing the
> > corresponding result is said to "delay the record".
> >
> > Any sequence of filters, each of which don't delay the record, when
> > combined in a single stream, will not delay the record.  So much of
> > the time, you don't have or don't care about record delay.
> >
> > Delaying records doesn't into play until you get into non-trivial
> > multiple-stream PIPElines, where you have split a data stream into two
> > and then later combine them.  In order for the right records to arrive
> > at the desired time at the joining point, you may need to take record
> > delay into account.  This is something that is impossible in UNIX (at
> > this time), because UNIX piping data flow is not deterministic.
> >
> > Beginning pipers don't usually run into the issue.  For one, there is
> > so much you can do with REXX and single stream PIPElines.  For
> > another, 

Re: REXX as JCL replacement

[John McKown]

On Wed, Jul 11, 2018 at 12:01 PM Jesse 1 Robinson 
wrote:

> This thread is entertaining but largely cherry-pie-in-the-sky. While it
> might be a nice exercise for sysprogs and architects, what's missing so far
> is a compelling business case to justify the pain and agony of actually
> replacing JCL in a real world environment. For a mature shop with thousands
> of jobs to manage--most of which work very well most of the time--it would
> be a very hard sell to justify resources to build a replacement that would
> mostly work better most of the time.
>

​I agree. If whatever it is does not have something to do automated restart
similar to what I'm used to with CA-7, the production schedulers would
likely kill any programmer who tried to use it to run something in
production. I, like many here, am old enough to remember how much of a PITA
it was to restart a job when a step failed for some reason. Mainly deleting
datasets, but also changing GDG relative generation numbers if the restart
is after the step which created the new GDG which is used in subsequent
steps. {shudder}​



>
> I'm reminded of the old saw about teaching a dog to walk on its hind legs.
> What's compelling is not that the dog does it well but merely that she can
> walk that way at all. Worth maybe admission to a vaudeville show but not a
> reason to turn your life upside down.
> .
> .
> 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


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

[Seymour J Metz]

Do you have a link to the WFL reference?


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


From: IBM Mainframe Discussion List  on behalf of 
ITschak Mugzach 
Sent: Wednesday, July 11, 2018 6:20 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement

Speaking of replacing JCL, how about unisys WFL? It's a programming
language dedicated to job flows. BTW, I am happy with jcl...

ITschak

On Wed, Jul 11, 2018 at 12:09 PM Tony Thigpen  wrote:

> So where does JOL get all the other informatoin for the DD card? Is
> there some back-end database that has information for all the files that
> may be used?
>
> Tony Thigpen
>
> Clem Clarke wrote on 07/10/2018 08:33 PM:
> > Below is an example of Jol, and the equivalent JCL.
> >
> > Clem
> >
> > Simplified Jol Scripting Language for Z/OS, TSO, Linux and Windows
> >
> > Payroll: Job class C 1000 k;
> > Exec Validate Input.Trans, Trans.Action(+1); /* Validate Transations */
> > if Validate=0
> > then do;
> >  Sort transaction(+1) to Sorted.Trans.Actions(+1)
> >  Fields(10,10,CH,A);
> >  Exec Update Payroll.Master(0), Sorted.Trans.Action(+1),
> >  Payroll.Master(+1);
> >  If Update = 0
> >  then do;
> >  Catalog Payroll.Master(+1), Sorted.Trans.Action(+1);
> >  Submit Job2;
> >  end;
> > end;
> > else Stop 'Error in PAYROLL Job';
> >
> >
> > 
> >
> > Equivalent Existing Job Control Language
> >
> >
> > //PAYROLL   JOB  CLASS=C,REGION=1000K
> > //VALIDATE   EXEC PGM=VALIDATE
> > //SYSPRINT   DD   SYSOUT=*
> > //INTRANSDD   DSN=INPUT.TRANS,DISP=SHR
> > //OUTTRANS   DD   DSN=TRANS.ACTIONS(+1),DISP=(NEW,PASS),
> > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
> > //SPACE=(CYL,(10,10),RLSE),
> > //UNIT=SYSDA,VOL=SER=WORK01
> > //SORT   EXEC PGM=SORT,COND=(VALIDATE,NE,0)
> > //SYSOUT DD   SYSOUT=*
> > //SORTWK01   DD   UNIT=SYSDA,SPACE=(CYL,20)
> > //SORTWK02   DD   UNIT=SYSDA,SPACE=(CYL,20)
> > //SORTWK03   DD   UNIT=SYSDA,SPACE=(CYL,20)
> > //SORTIN DD   DSN=TRANS.ACTIONS(+1),DISP=(SHR,PASS)
> > //SORTOUTDD   DSN=SORTED.TRANS.ACTIONS(+1),
> > //DISP=(NEW,PASS),
> > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
> > //SPACE=(CYL,(10,10),RLSE),
> > //UNIT=SYSDA,VOL=SER=WORK01
> > //SYSIN  DD   *
> >  SORT FIELDS=(10,10,CH,A)
> > //UPDATE EXEC PGM=UPDATE,COND=(VALIDATE,NE,0)
> > //SYSPRINT   DD   SYSOUT=*
> > //MASTIN DD   DSN=PAYROLL.MASTER(0),DISP=SHR
> > //TRANS  DD   DSN=TRANS.ACTION(+1),DISP=(SHR,PASS)
> > //MASTOUTDD   DSN=PAYROLL.MASTER(+1),DISP=(NEW,PASS),
> > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
> > //SPACE=(CYL,(10,10),RLSE),
> > //UNIT=SYSDA,VOL=SER=WORK01
> > //CATLG  EXEC PGM=IEFBR14,COND=(UPDATE,NE,0)
> > //DUMMY1 DD   DSN=PAYROLL.MASTER(+1),DISP=(SHR,CATLG)
> > //DUMMY2 DD   DSN=SORTED.TRANS.ACTIONS(+1),
> > //DISP=(SHR,CATLG)
> > //SUBMIT EXEC PGM=IEBGENER,COND=(UPDATE,NE,0)
> > //SYSPRINT   DD   SYSOUT=*
> > //SYSUT1 DD   DSN=SUBMIT.LIBRARY(JOB2),DISP=SHR
> > //SYSUT2 DD   SYSOUT=(*,INTRDR)
> > //SYSIN  DD   DUMMY
> > //ERRMSG EXEC PGM=SHOWERR,COND=(VALIDATE,EQ,0),
> > //   PARM='Error in PAYROLL Job'
> >
> >
> >
> > 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.
> >>
> >> 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 

Re: Using JCL Symbld and TYPRUN=SCAN

[John McKown]

On Wed, Jul 11, 2018 at 11:57 AM Tom Brennan 
wrote:

> I've always considered DD's one of the major differences between MVS and
> other platforms.  I remember one of my first BASIC programs in college
> where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1"
> and sort.  The first thing I thought of was, "So we have to update the
> program every time we want to sort a different file?"
>
> DD redirection:  Genius, whoever thought of it.
>

​I've seen a lot of UNIX programs which implement the same concept using
shell environment variables. Simple, universal almost, examples are
${HOME}, ${TMPDIR} (and variants), ${CLASSPATH} for Javca, ${PATH}​ for an
//STEPLIB equivalent.

I have a PERL script which implements this. When run, you can specify the
"database name" (PostgreSQL) using --dbname= on the command. If not
specified, it will look for the DBNAME environment variable. If neither,
then it takes a default.



>
> On 7/11/2018 8:40 AM, Steve Smith wrote:
>
> > DDNAMEs are a pretty nice feature of z/OS!  So you *don't* have to pass a
> > bunch of (potentially very long) file names.  DDNAMEs can be thought of
> as
> > a limited form of environment variables.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
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: Deleting all members of a PDS

[Lizette Koehler]

You might try using INFILE and specify a DD with DISP=SHR

Or got cbttape.org and download PDSCLEAN - works great for PDS and PDS/E
datasets

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Jesse 1 Robinson
> Sent: Wednesday, July 11, 2018 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Deleting all members of a PDS
> 
> While installing a new version of the PDS command-one that works on z/OS 2.3
> as previously discussed here-we need to empty existing libraries in order to
> refill them with new members. Without a working PDS command, we had to find a
> different way to accomplish FIXPDS RESETDIR.
> 
> I finally remembered the relatively new DELETE pds-dsn(*), which accomplishes
> the task nicely. However, like IDCAMS DELETE in general, my testing indicates
> that it wants exclusive enqueue on the PDS. Not a problem for most PDS data
> sets, but a link listed library must contend with XCFAS and LLA. I know that
> both of those can be handled fairly easily, but I'm curious if there's some
> additional keyword that will ignore the SHR enqueues. I have not found
> anything.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.com
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Deleting all members of a PDS

[Jesse 1 Robinson]

While installing a new version of the PDS command-one that works on z/OS 2.3 as 
previously discussed here-we need to empty existing libraries in order to 
refill them with new members. Without a working PDS command, we had to find a 
different way to accomplish FIXPDS RESETDIR.

I finally remembered the relatively new DELETE pds-dsn(*), which accomplishes 
the task nicely. However, like IDCAMS DELETE in general, my testing indicates 
that it wants exclusive enqueue on the PDS. Not a problem for most PDS data 
sets, but a link listed library must contend with XCFAS and LLA. I know that 
both of those can be handled fairly easily, but I'm curious if there's some 
additional keyword that will ignore the SHR enqueues. I have not found anything.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


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

Re: IEC614I Scratch

[Lizette Koehler]

If you have Mark Zelden's IPLINFO - it can show which parmlib members are in 
effect and I think where they were loaded from

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Mark Jacobs - Listserv
> Sent: Wednesday, July 11, 2018 5:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEC614I Scratch
> 
> One of the parmlb datasets. If you have command access, issue a D PARMLIB
> command for the list of datasets in use. You can also issue a D MPF command
> which should show the active list too.
> 
> Hervey Martinez wrote on 7/11/18 8:35 AM:
> 
> Hey Mark,
> 
> 
> I normally are looking up parms. What parm library is this in? zos?
> 
> 
> Hervey
> 
> 
> 
> From: IBM Mainframe Discussion List  m...@listserv.ua.edu> on behalf of Mark Jacobs - Listserv
> 
> Sent: Monday, July 9, 2018 3:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEC614I Scratch
> 
> 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?
> 
> 
> 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 .com>'.
> 
> 
> 
> --
> 
> Mark Jacobs
> Time Customer Service
> Global Technology Services
> 
> The standard you walk past is the standard you accept.
> Lt. Gen. David Morrison
> 
> 
> 
> 
> --
> 
> Mark Jacobs
> Time Customer Service
> Global Technology Services
> 
> The standard you walk past is the standard you accept.
> Lt. Gen. David Morrison
> 

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

RCNVTCAT questions

[Andrew Arentsen]

Hello,

I am looking at cloning a master catalog using the RCNVTCAT program.  The 
intent is to use the NEW master catalog going forward. The NEW master 
catalog will be defined to be shared and have symbols defined for using 
indirect cataloging.

 I have run RCNVTCAT and it looks like it was successful. the following 
members were created.
ALIAS 
GDG 
IMPORT 
 MISC 
NONVSAM 
RECAT 
REPORT 
SYSCTLG 
SYS1 

I will be running the jobs with the idcams commands on the system of the 
master catalog that is being cloned.

After the new master catalog is defined.
 My questions
  1) is there a specific order to run the created idcams commands.
  2) do i need to allocate new PAGE datasets in the new master catalog or 
can they be 'recataloged'
  3) there are commands in the RECAT member to recatalog VVDS's. how will 
that work?  will the VVDS's then point at the new master catalog?

Andrew Arentsen
Senior Mainframe Systems Engineer
Phone: 800.242.7666 x1349

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

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

Re: REXX as JCL replacement

[Jesse 1 Robinson]

This thread is entertaining but largely cherry-pie-in-the-sky. While it might 
be a nice exercise for sysprogs and architects, what's missing so far is a 
compelling business case to justify the pain and agony of actually replacing 
JCL in a real world environment. For a mature shop with thousands of jobs to 
manage--most of which work very well most of the time--it would be a very hard 
sell to justify resources to build a replacement that would mostly work better 
most of the time.  

I'm reminded of the old saw about teaching a dog to walk on its hind legs. 
What's compelling is not that the dog does it well but merely that she can walk 
that way at all. Worth maybe admission to a vaudeville show but not a reason to 
turn your life upside down. 
.
.
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 Hobart Spitz
Sent: Wednesday, July 11, 2018 9:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: REXX as JCL replacement

Gil wrote:
>SORT is quasi-batch:
A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can run
SORT(s) to completion completely independently of the main pipe, to name just 
two possibilities.  The terminology in the PIPElines documentation is "delaying 
records".  Most built-in filters don't delay records, others might delay some 
records some of the time, and others, like SORT delay, of necessity, all 
records.  Any filter that has to hold on to a record and "think about it" 
before producing the corresponding result is said to "delay the record".

Any sequence of filters, each of which don't delay the record, when combined in 
a single stream, will not delay the record.  So much of the time, you don't 
have or don't care about record delay.

Delaying records doesn't into play until you get into non-trivial 
multiple-stream PIPElines, where you have split a data stream into two and then 
later combine them.  In order for the right records to arrive at the desired 
time at the joining point, you may need to take record delay into account.  
This is something that is impossible in UNIX (at this time), because UNIX 
piping data flow is not deterministic.

Beginning pipers don't usually run into the issue.  For one, there is so much 
you can do with REXX and single stream PIPElines.  For another, multi-stream 
PIPElines require a small additional level of knowledge concerning 
functionality and syntax.  Melinda Varian has written some excellent papers and 
talks on PIPElines.  She was a long time advocate and
champion of PIPElines, especially under z/VM and CMS.   You can find her
papers and more at

http://vm.marist.edu/~pipeline/

The author's edition, the primary source of PIPElines information, can be found 
at.

http://www-01.ibm.com/support/docview.wss?uid=pub1sl26001805

You need only read the first few chapters before you will start drooling to 
have the product.  No joke.  You'll begin to realize how much your productivity 
has been hampered by not having better tools at your disposal.

I capitalize PIPElines this way because, apparently, there is a UNIX pipe 
command which has no connection or similarity to the TSO/CMS product.


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 11, 2018 at 11:54 AM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 11 Jul 2018 11:03:05 -0400, Tony Thigpen wrote:
>
> >Using pipelines could require a lot of programming changes.
> >Historically, programs tend to be designed to process batches, not
> records.
> >
> >Most shops will not have the bodies to do the changes needed.
> >
> Many programs process data sequentially and are well suited to using 
> pipes, which merely bypass temporary files and require no other changes.
>
> In ancient, main-storage-constrained environments pipes might actually 
> degrade performance: having multiple programs co-resident caused 
> paging I/O that overwhelmed any benefit of less temp file I/O.
>
> SORT is (too) often given as an example of a pipe stage.  It can be 
> inappropriate because SORT is quasi-batch:  SORT can not write the 
> first record to SORTOUT until it reads the last record from SORTIN.
>
> >I like the idea of REXX as a JCL replacement. It can provide a lot 
> >better logic. I don't know that it will make many inroads due to lack 
> >of man-power, but it can be a method to the future.
> >
> >One of our staff looked seriously at JOL and rejected it.
>
> -- gil


--
For IBM-MAIN subscribe / signoff / 

Re: Using JCL Symbld and TYPRUN=SCAN

[Tom Brennan]

I've always considered DD's one of the major differences between MVS and 
other platforms.  I remember one of my first BASIC programs in college 
where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1" 
and sort.  The first thing I thought of was, "So we have to update the 
program every time we want to sort a different file?"


DD redirection:  Genius, whoever thought of it.

On 7/11/2018 8:40 AM, Steve Smith wrote:


DDNAMEs are a pretty nice feature of z/OS!  So you *don't* have to pass a
bunch of (potentially very long) file names.  DDNAMEs can be thought of as
a limited form of environment variables.


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

[Hobart Spitz]

Gil wrote:
>SORT is quasi-batch:
A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can run
SORT(s) to completion completely independently of the main pipe, to name
just two possibilities.  The terminology in the PIPElines documentation is
"delaying records".  Most built-in filters don't delay records, others
might delay some records some of the time, and others, like SORT delay, of
necessity, all records.  Any filter that has to hold on to a record and
"think about it" before producing the corresponding result is said to
"delay the record".

Any sequence of filters, each of which don't delay the record, when
combined in a single stream, will not delay the record.  So much of the
time, you don't have or don't care about record delay.

Delaying records doesn't into play until you get into non-trivial
multiple-stream PIPElines, where you have split a data stream into two and
then later combine them.  In order for the right records to arrive at the
desired time at the joining point, you may need to take record delay into
account.  This is something that is impossible in UNIX (at this time),
because UNIX piping data flow is not deterministic.

Beginning pipers don't usually run into the issue.  For one, there is so
much you can do with REXX and single stream PIPElines.  For another,
multi-stream PIPElines require a small additional level of knowledge
concerning functionality and syntax.  Melinda Varian has written some
excellent papers and talks on PIPElines.  She was a long time advocate and
champion of PIPElines, especially under z/VM and CMS.   You can find her
papers and more at

http://vm.marist.edu/~pipeline/

The author's edition, the primary source of PIPElines information, can be
found at.

http://www-01.ibm.com/support/docview.wss?uid=pub1sl26001805

You need only read the first few chapters before you will start drooling to
have the product.  No joke.  You'll begin to realize how much your
productivity has been hampered by not having better tools at your disposal.

I capitalize PIPElines this way because, apparently, there is a UNIX pipe
command which has no connection or similarity to the TSO/CMS product.


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 11, 2018 at 11:54 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 11 Jul 2018 11:03:05 -0400, Tony Thigpen wrote:
>
> >Using pipelines could require a lot of programming changes.
> >Historically, programs tend to be designed to process batches, not
> records.
> >
> >Most shops will not have the bodies to do the changes needed.
> >
> Many programs process data sequentially and are well suited to using pipes,
> which merely bypass temporary files and require no other changes.
>
> In ancient, main-storage-constrained environments pipes might actually
> degrade performance: having multiple programs co-resident caused
> paging I/O that overwhelmed any benefit of less temp file I/O.
>
> SORT is (too) often given as an example of a pipe stage.  It can be
> inappropriate because SORT is quasi-batch:  SORT can not write the
> first record to SORTOUT until it reads the last record from SORTIN.
>
> >I like the idea of REXX as a JCL replacement. It can provide a lot
> >better logic. I don't know that it will make many inroads due to lack of
> >man-power, but it can be a method to the future.
> >
> >One of our staff looked seriously at JOL and rejected it.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: SUSE splits from Microfocus

[Tomasz Rola]

On Tue, Jul 03, 2018 at 09:02:41PM -0400, Phil Smith III wrote:
> David W Noon wrote:
> 
[...]
> >A lot of the old EDS mainframers were made redundant because HP felt the
> 
> >mainframe was dead. The mainframe now helps to keep HPE alive.
> 
>  
> 
> How's that? HPE NonStop isn't a mainframe. x86 servers aren't mainframes. I
> don't understand.

Perhaps they mean VAX and Alpha-based computers - I believe those had
been acquired from DEC via Compaq and they (HP) were supporting both
VAXen and Alphas, at least before the split. I may be wrong, however,
and I have no time to check my notes/sources.

I wonder if it is still possible to get VAX VMS from them (whoever
"them" may be nowadays, HPE?) - it was possible to do so, by paying
some tens of bucks for membership in their hobbyist group. After that
one could download iso and licences.

I think that back in time, PDP-10 was being called a mainframe, too.

Likewise, a computer running Multics probably deserves to be called a
mainframe. But there are maybe two of them, globally? Plus some being
run as emulators, even giving accounts to interested public (and same
with public VAXen, there are/were few of them on the net, one could
login as guest and/or apply for normal account).

So, it was not only z, some time ago.

BTW, would it count as a mainframe if I ran one inside emulator on PC?

-- 
Regards,
Tomasz Rola

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

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Paul Gilmartin]

On Wed, 11 Jul 2018 11:40:19 -0400, Steve Smith wrote:

>Not sure if this was pointed out before, but DDNAMEs are required by z/OS
>access methods, not JCL.  There is no reason these or dataset names need to
>be arguments just because REXX is used instead of JCL.
> 
Most programs that don't expose DDNAMEs externaly create them internally
using DYNALLOC.  This is true for z/OS Rexx, not for CMS Rexx.

>DDNAMEs are a pretty nice feature of z/OS!  So you *don't* have to pass a
>bunch of (potentially very long) file names.  DDNAMEs can be thought of as
>a limited form of environment variables.
>
It stretches the understanding, but, yes.  In the UNIX environment, descriptors
perform much the same function as DDNAMES in the OS environment.

-- gil

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

Re: Z114 to z14 experience any ?

[Jake Anderson]

Absolutely we have looked into that aspect.. however wanted to know if
there was any known issues


Thanks again for all the great answer

On Wed 11 Jul, 2018, 6:27 PM R.S.,  wrote:

> W dniu 2018-07-11 o 06:07, Jake Anderson pisze:
> > Hi
> >
> > Has anyone moved your z hardware from z114 to z14 ?
> >
> > Any gotchas and how was your migration experience ?
> >
> > We are at zOS 2.2 with z114.
> >
>
> People gave you wise answers, however to complement it: check your PTFs.
> z/OS 2.2 should be patched to recognize z14 hardware.
> Look at Fixcat or PSP bucket.
>
> --
> 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
>

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

[Paul Gilmartin]

On Wed, 11 Jul 2018 11:03:05 -0400, Tony Thigpen wrote:

>Using pipelines could require a lot of programming changes.
>Historically, programs tend to be designed to process batches, not records.
>
>Most shops will not have the bodies to do the changes needed.
> 
Many programs process data sequentially and are well suited to using pipes,
which merely bypass temporary files and require no other changes.

In ancient, main-storage-constrained environments pipes might actually
degrade performance: having multiple programs co-resident caused
paging I/O that overwhelmed any benefit of less temp file I/O.

SORT is (too) often given as an example of a pipe stage.  It can be
inappropriate because SORT is quasi-batch:  SORT can not write the
first record to SORTOUT until it reads the last record from SORTIN.

>I like the idea of REXX as a JCL replacement. It can provide a lot
>better logic. I don't know that it will make many inroads due to lack of
>man-power, but it can be a method to the future.
>
>One of our staff looked seriously at JOL and rejected it.

-- gil

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

Allocating VSAM in JCL was Re: z/OS JCl vs. VSE JCL: VSAM files

[Clark Morris]

[Default] On 10 Jul 2018 15:33:56 -0700, in bit.listserv.ibm-main
johnrcl...@gmail.com (John Clifford) wrote:

>it is not the default but is the only correct way to access a vsam file.
>disp=shr,dsn=.vsam (possible bufno,bufni,...etc)
>
>Never disp=new or delete.   Disp=old can be used if you need to make sure
>you are the only one accessing the file but if it is open in CICS it will
>hang.

As of over 13 years ago, you could allocate a VSAM file in JCL and
even a temporary one.  I never used the facility but it is there.

Clark Morris
>
>On Tue, Jul 10, 2018 at 6:07 PM, Tony Thigpen  wrote:
>
>> So, DISP=SHR is not the default, as I thought was implied by John's
>> statement that "Z/os VSAM is always accessed as DISP=SHR."
>>
>> Tony Thigpen
>>
>> Gibney, Dave wrote on 07/10/2018 05:49 PM:
>>
>>> If DISP=SHR (that is if not DISP is provided), then the JCL Default of
>>> (NEW,PASS) would happen and the job would fail
>>>
>>> -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Tony Thigpen
 Sent: Tuesday, July 10, 2018 2:43 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: z/OS JCl vs. VSE JCL: VSAM files

 Then, why does every VSAM DD for every z/OS site I have worked with,
 always include DISP=SHR?
 (I guess, because it's a habit from non-VSAM files and nobody told them
 they
 did not have to do it.)

 Tony Thigpen

 John Clifford wrote on 07/10/2018 04:16 PM:

> Z/os VSAM is always accessed as  DISP=SHR.
>

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

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

[Hobart Spitz]

It may be a long, slow process, generally and/or at some sites, but if
enough people do it,  JCL will become the exception.  IBM and site
management will get it, and additional needed tools/solutions or something
even better will be made available.   Eventually.

Try it.  Use what works.  Refine what doesn't.



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 11, 2018 at 11:03 AM, Tony Thigpen  wrote:

> Using pipelines could require a lot of programming changes. Historically,
> programs tend to be designed to process batches, not records.
>
> Most shops will not have the bodies to do the changes needed.
>
> I like the idea of REXX as a JCL replacement. It can provide a lot better
> logic. I don't know that it will make many inroads due to lack of
> man-power, but it can be a method to the future.
>
> One of our staff looked seriously at JOL and rejected it.
>
> Tony Thigpen
>
> Hobart Spitz wrote on 07/11/2018 08:37 AM:
>
>> The JOL effort is commendable, but replacing JCL is about much more than a
>> nicer syntax or easy movement between foreground and background.
>>
>> At the risk of repetition, other reasons are (1) to eliminate the
>> separation between scripting code and application code and (2) to
>> interface
>> with other software/data (files, DB2, ISPF, etc.).
>>
>> Resistance to replacing JCL comes from the fact that "everybody knows JCL"
>> (which they don't really).  Everybody (in the target audience) knows REXX,
>> if not directly, then because REXX has many well-know features of other
>> languages.  JCL resembles only mainframe assembler.
>>
>> Add in PIPElines and you get a productivity and performance improvements
>> unlike any other option available.  Charles's example in REXX and
>> PIPElines
>> might look like this.
>>
>> 1. "pipe (end ?) ? < trans | v: validate | g: gate",
>> 2.   "? v: sort 10.10 | g:| u: update | >" GDG("payroll.master(+1)")",
>> 3.   "? <" GDG("payroll.master(0)") | u:"
>> 4.
>> 5. if RC = 0 then
>> 6. "submit job2"
>> 7. else
>> 8. "delete" GDG("payroll.master(0)")
>>
>>
>> I tried to stay true to Charles's example.  If you can to skip invalid
>> transactions, but still process valid ones (a reasonable approach), you
>> can
>> eliminate the GATE and combine the first two streams.
>>
>> GDG() is a function that I've previously written.
>>
>> Note that zero intermediate files are needed, saving those I/O operations.
>>
>> I haven't read the details of JOL, so I might be missing something.  I'm
>> happy to be educated.
>>
>>
>> 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 11, 2018 at 6:40 AM, David Crayford 
>> wrote:
>>
>> On 11/07/2018 7:19 AM, Clem Clarke wrote:
>>>
>>> Don't know about that! I always think that IBM has some of the best
 people and concepts.  Pity IBM didn't push PL/I instead od allowing C to
 rule the world.


 They did, but something that's free will always be more attractive.
>>> Multics was originally written in PL/I but the UNIX devs didn't think it
>>> was suitable for operating systems.
>>>
>>> However, there's an interesting IBM lab in Perth that has some excellent
>>>
 people. Not many people know about it.


>>> Not any more! They all got the push when IBM recently cut their
>>> workforce.
>>> A few of them moved to HCL with the PD products. The rest of them are
>>> looking for work.
>>>
>>>
>>> --
>>> 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: Using JCL Symbld and TYPRUN=SCAN

[Steve Smith]

Not sure if this was pointed out before, but DDNAMEs are required by z/OS
access methods, not JCL.  There is no reason these or dataset names need to
be arguments just because REXX is used instead of JCL.

DDNAMEs are a pretty nice feature of z/OS!  So you *don't* have to pass a
bunch of (potentially very long) file names.  DDNAMEs can be thought of as
a limited form of environment variables.

sas

On Wed, Jul 11, 2018 at 10:51 AM, Hobart Spitz  wrote:

> Andrew wrote:
>
> ​...
>
> >The connection between program (DDNAME) and resources (dataset etc.) is
> nice too. In something like Rexx you need to pass the names as arguments
> (JCL is >much better than one long command line) or hard code them.
>
> That's only because z/OS is so JCL oriented.  Again, this works in IBM (and
> shareholders) favor.  It's harder to leave for another platform.
>

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

Re: z/OS JCl vs. VSE JCL: VSAM files

[John McKown]

On Wed, Jul 11, 2018 at 8:36 AM Steve Smith  wrote:

> DISP=NEW or OLD is perfectly valid for VSAM and PDSEs.  PDSEs presumably
> use some kind of hidden paging interface like LINEAR and ZFS do, but are
> not VSAM.
>

AFAIK, these use "Media Manager" for their I/O instead of the historic EXCP
or EXCPVR. "Media Manager" is not documented. I think the documentation is
only available to ISPs under an NDA; for a high cost and with no updates
included.



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


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

[Tony Thigpen]

Using pipelines could require a lot of programming changes. 
Historically, programs tend to be designed to process batches, not records.


Most shops will not have the bodies to do the changes needed.

I like the idea of REXX as a JCL replacement. It can provide a lot 
better logic. I don't know that it will make many inroads due to lack of 
man-power, but it can be a method to the future.


One of our staff looked seriously at JOL and rejected it.

Tony Thigpen

Hobart Spitz wrote on 07/11/2018 08:37 AM:

The JOL effort is commendable, but replacing JCL is about much more than a
nicer syntax or easy movement between foreground and background.

At the risk of repetition, other reasons are (1) to eliminate the
separation between scripting code and application code and (2) to interface
with other software/data (files, DB2, ISPF, etc.).

Resistance to replacing JCL comes from the fact that "everybody knows JCL"
(which they don't really).  Everybody (in the target audience) knows REXX,
if not directly, then because REXX has many well-know features of other
languages.  JCL resembles only mainframe assembler.

Add in PIPElines and you get a productivity and performance improvements
unlike any other option available.  Charles's example in REXX and PIPElines
might look like this.

1. "pipe (end ?) ? < trans | v: validate | g: gate",
2.   "? v: sort 10.10 | g:| u: update | >" GDG("payroll.master(+1)")",
3.   "? <" GDG("payroll.master(0)") | u:"
4.
5. if RC = 0 then
6. "submit job2"
7. else
8. "delete" GDG("payroll.master(0)")

I tried to stay true to Charles's example.  If you can to skip invalid
transactions, but still process valid ones (a reasonable approach), you can
eliminate the GATE and combine the first two streams.

GDG() is a function that I've previously written.

Note that zero intermediate files are needed, saving those I/O operations.

I haven't read the details of JOL, so I might be missing something.  I'm
happy to be educated.


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 11, 2018 at 6:40 AM, David Crayford  wrote:


On 11/07/2018 7:19 AM, Clem Clarke wrote:


Don't know about that! I always think that IBM has some of the best
people and concepts.  Pity IBM didn't push PL/I instead od allowing C to
rule the world.



They did, but something that's free will always be more attractive.
Multics was originally written in PL/I but the UNIX devs didn't think it
was suitable for operating systems.

However, there's an interesting IBM lab in Perth that has some excellent

people. Not many people know about it.



Not any more! They all got the push when IBM recently cut their workforce.
A few of them moved to HCL with the PD products. The rest of them are
looking for work.


--
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: Using JCL Symbld and TYPRUN=SCAN

[Hobart Spitz]

Andrew wrote:

>I actually like JCL. One of the things it does so well that no-one even
notices is allocation of resources.

Then you haven't fully considered the alternatives.  That's not a
criticism, just a statement of fact.  How many of us really know how our
computers, cars, phones, bodies or anything else we live with day to day,
really work, at least until they don't, then we start caring.

Here's an actual example:  I was riding in the back of an Uber recently,
and I felt every single bump, as if the chassis was bottoming out.  I asked
some casual questions of the driver about the car.  She said she bought it
used and tires kept exploding when she hit a pothole.  I'd never had
exploding tire, so I suggested that the cause might be that her shocks
weren't not doing the job they were intended for, i.e. mitigating
irregularities in the roadway.  (Consider a pothole a large value of
irregularity.)

The point is, you can proceed for a long time without understanding what
your tools are doing for you, but the day may come when you (or someone
else) will need to have that knowledge.

>In a previous job I tried to write scripts on a unix system to try to fix
tasks that had a tendency to open one file and then wait for another, where
multiple tasks >were deadlocking.

It may take a little more skill and experience to write in a real scripting
language than in JCL, but it should be done.  I submit that this attitude
contributes to the high cost of running z/OS.  The many things that happen
in batch are hidden, and IMHO, contribute to greater "large system effect"
than with leaner operating systems such as z/VM, *nix and *nix
derivatives.   IBM and its stockholders love it when your company has to
spend more on hardware, especially when that hardware is so cheap to make
that they can afford to ship you 16 processors, when your company only
orders and pays for 1.

>This is so simple with JCL because you don't get one allocation until you
get them all.

That's what my suggested host command/function would do.  It would probably
have a behaviour that would allow it to be used only once, to prevent
deadlocks, unless all previous ENQs were freed.  The second use, without
FREE, could cause a JOB cancelation, possibly unconditionally, so that
well-meaning misuse would be discouraged, or, alternatively, only if the
ENQs could not be satisfied.

>The connection between program (DDNAME) and resources (dataset etc.) is
nice too. In something like Rexx you need to pass the names as arguments
(JCL is >much better than one long command line) or hard code them.

That's only because z/OS is so JCL oriented.  Again, this works in IBM (and
shareholders) favor.  It's harder to leave for another platform.

Gil wrote:

>Have you a realistic alternative?

For starters, consider something that uses REXX syntax and JCL semantics:


   1.
*/* REXX */ *
   2.
*arg String /* From SUBMIT or start task command. */ *
   3.
*"jcl myjob: job (acct),'john smith',class=t,msgclass=h,notify="userid()" *
   4.
*"jcl exec pgm=myprog,parm="date("s") *
   5.
*"jcl sysprint: dd sysout=*"  *
   6. *...*

The JCL host command could create the exact same control blocks and
structures as the existing JCL statements today.  When the REXX exec
exited, ENQs would be processed as now, followed by the current processing,
including step execution, and cleanup.  All exits would be preserved so
that third-party software would still work unchanged.  The JCL EXEC host
command could generate code to set RC.stepname supporting condition code
testing, and the JCL DD host command could set stepname.ddname.DSN, etc.,
to allow for reference to all parameters.  This approach would, however,
limit the benefits of batch REXX.

I'm sure there are lots of other ways to do it.  Use more DB2 and PDSEs.  A
combination of REXX and PIPElines means that temporary datasets, and their
2 (or more) can be replaced with just one single character.

>In one case, I was able to enumerate a superset of the
>DSNs I might want to allocate in a Rexx step.  I added EXEC
PGM=IEFBR14,COND=(0,LE)
>with DD statements for those at the end of the job just to avoid ENQ
surprises.
>JCL automates the enumeration of the ENQs; DYNALLOC, a newcomer, doesn't
>play by the old rules.

I use this technique when all else fails, and recommend it with one
exception.  Put that those DDs in the first step of the job.  You can FREE
something you won't need in the rest of the JOB, in case another
JOB/process might need it, without risking a deadly embrace.

I do advocate a combined REXX and PIPElines environment as a replacement
for JCL; z/VM works swimmingly with it.  Perhaps z/OS fossilized thinking
is why the best things in z/OS (DB2, REXX, PIPElines) came from z/VM.  We'd
all be just as happy if *nix could offer the same productivity and
performance benefits.  Doing things character by character is just as bad
and old as JCL.  That needs to change.

OREXXMan
JCL is the buggy whip of 21st century computing.  

Re: REXX as JCL replacement

[Seymour J Metz]

> Resistance to replacing JCL comes from the fact that "everybody knows JCL"

I haven't seen resistance to replacing JCL, just resistance to removing 
functionality and doubt as to feasibility. So far nothing that has been 
proposed actually does what JCL does.

That said, there's lots of room for improvement.


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


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

The JOL effort is commendable, but replacing JCL is about much more than a
nicer syntax or easy movement between foreground and background.

At the risk of repetition, other reasons are (1) to eliminate the
separation between scripting code and application code and (2) to interface
with other software/data (files, DB2, ISPF, etc.).

Resistance to replacing JCL comes from the fact that "everybody knows JCL"
(which they don't really).  Everybody (in the target audience) knows REXX,
if not directly, then because REXX has many well-know features of other
languages.  JCL resembles only mainframe assembler.

Add in PIPElines and you get a productivity and performance improvements
unlike any other option available.  Charles's example in REXX and PIPElines
might look like this.

   1. "pipe (end ?) ? < trans | v: validate | g: gate",
   2.   "? v: sort 10.10 | g:| u: update | >" GDG("payroll.master(+1)")",
   3.   "? <" GDG("payroll.master(0)") | u:"
   4.
   5. if RC = 0 then
   6. "submit job2"
   7. else
   8. "delete" GDG("payroll.master(0)")

I tried to stay true to Charles's example.  If you can to skip invalid
transactions, but still process valid ones (a reasonable approach), you can
eliminate the GATE and combine the first two streams.

GDG() is a function that I've previously written.

Note that zero intermediate files are needed, saving those I/O operations.

I haven't read the details of JOL, so I might be missing something.  I'm
happy to be educated.


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 11, 2018 at 6:40 AM, David Crayford  wrote:

> On 11/07/2018 7:19 AM, Clem Clarke wrote:
>
>> Don't know about that! I always think that IBM has some of the best
>> people and concepts.  Pity IBM didn't push PL/I instead od allowing C to
>> rule the world.
>>
>>
> They did, but something that's free will always be more attractive.
> Multics was originally written in PL/I but the UNIX devs didn't think it
> was suitable for operating systems.
>
> However, there's an interesting IBM lab in Perth that has some excellent
>> people. Not many people know about it.
>>
>
> Not any more! They all got the push when IBM recently cut their workforce.
> A few of them moved to HCL with the PD products. The rest of them are
> looking for work.
>
>
> --
> 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: REXX as JCL replacement

[zMan]

On Wed, Jul 11, 2018 at 6:40 AM, David Crayford  wrote:

> However, there's an interesting IBM lab in Perth that has some excellent
>> people. Not many people know about it.
>>
>
> Not any more! They all got the push when IBM recently cut their workforce.
> A few of them moved to HCL with the PD products. The rest of them are
> looking for work.
>

I'm afraid that when I read Clem's statement, my immediate thought was,
"You probably mean 'WAS an interesting IBM lab...'". Sorry to hear that I
was correct.

IBM really seems to be in a death-spiral. Very sad.

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

[Elardus Engelbrecht]

Peter Hunkeler wrote:

>>Perhaps the OP should also put in the "estimate" on how big the input for all 
>>the sorting work is in other terms. 
>>Something like this: Have REGION= and OPTION 
>>DYNSPC=512,SIZE=E9,MAINSIZE=MAX (which is working for my hungry sort 
>>jobs.) 

>The OP (me :-) wrote in the initial post that the application *cannot* provide 
>an estimate.

Sorry, I forgot about that 'cannot provide estimate'. Thanks for sorting me 
out. ;-)


>I did not write about the fact that DFSORT sometimes decides it cannot do 
>in-memory sorting because it would hurt the overall system health. I did not 
>because that is not part of my questions. Be assured I do understand the 
>in-memory options DFSORT provides.

I see your dilemma. I hope you have great success with that PMR. Let us all 
know how that PMR is faring.

Good luck! All of the very best to you.

Groete / Greetings
Elardus Engelbrecht

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

Re: z/OS JCl vs. VSE JCL: VSAM files

[R.S.]

W dniu 2018-07-10 o 22:05, Farley, Peter x23353 pisze:

z/OS DISP=(OLD,DELETE) works without any problem to delete a VSAM cluster that 
you own.  I use that JCL all the time to delete test VSAM files.

Creating a VSAM cluster may often require IDCAMS DEFINE, but the JCL LIKE 
parameter is your friend if for instance you are making a copy of a production 
file for a unit test run.  Just use the UNIT and SPACE parameters to allocate 
space and all else will be copied from the LIKE cluster.


UNIT? That old JCL keyword commonly used in the dark ages before SMS?
;-)



Now if any of the LIKE cluster parameters are incompatible with your immediate 
need (REUSE vs NOREUSE perhaps, or LOG parameters for RLS) then you do need 
DEFINE, but the JCL DELETE works without an issue that I am aware of.


Sometimes DATACLAS=dataclass can help. So, you can use 
LIKE=ORIGINAL.CLUSTER,DATACLAS=NOREUSE,SPACE=(CYL,(10,10))



--
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: Z114 to z14 experience any ?

[R.S.]

W dniu 2018-07-11 o 06:07, Jake Anderson pisze:

Hi

Has anyone moved your z hardware from z114 to z14 ?

Any gotchas and how was your migration experience ?

We are at zOS 2.2 with z114.



People gave you wise answers, however to complement it: check your PTFs.
z/OS 2.2 should be patched to recognize z14 hardware.
Look at Fixcat or PSP bucket.

--
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: Primary & secondary space values in DFSORT's dynamic work space allocation.

[Vernooij, Kees (ITOPT1) - KLM]

Ok, I'm happy to see we have the same view on the (ahum) 'problem'.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: 11 July, 2018 16:17
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: Primary & secondary space values in DFSORT's dynamic
> work space allocation.
> 
> 
> >What is in fact the problem with this job, that the SORTWK
> specification should be changed from JCL to dynamic?
> [snip]
> 
> 
> I totally agree with all you write.
> 
> 
> I don't know, and honestly I don't understand why they were asked to do
> change. I was only contacted by the desperate developer when he
> recognized the change could lead to production job abends. This was just
> before the software delivery cycle.
> 
> 
> I tried to understand how the parameters for the dynamic allocation
> work, so as to be able to give good recommendation to them. By testing,
> I found that the DYNAPCT creates some reserve work space data sets, but
> the total space of *all* the reserve data sets is roughly the space of a
> *single* initial work data set. Doesn't make sense to me, and IBM seems
> to agree. Therefore the PMR.
> 
> 
> 
> 
> --
> Peter Hunkeler
> 
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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


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

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

[Peter Hunkeler]

>Perhaps the OP should also put in the "estimate" on how big the input for all 
>the sorting work is in other terms.

>Something like this: Have REGION= and OPTION 
>DYNSPC=512,SIZE=E9,MAINSIZE=MAX (which is working for my hungry sort 
>jobs.)




The OP (me :-) wrote in the initial post that the application *cannot* provide 
an estimate.


I did not write about the fact that DFSORT sometimes decides it cannot do 
in-memory sorting because it would hurt the overall system health. I did not 
because that is not part of my questions. Be assured I do understand the 
in-memory options DFSORT provides.




--
Peter Hunkeler



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

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

[Peter Hunkeler]

>What is in fact the problem with this job, that the SORTWK specification 
>should be changed from JCL to dynamic?
[snip]


I totally agree with all you write.


I don't know, and honestly I don't understand why they were asked to do change. 
I was only contacted by the desperate developer when he recognized the change 
could lead to production job abends. This was just before the software delivery 
cycle.


I tried to understand how the parameters for the dynamic allocation work, so as 
to be able to give good recommendation to them. By testing, I found that the 
DYNAPCT creates some reserve work space data sets, but the total space of *all* 
the reserve data sets is roughly the space of a *single* initial work data set. 
Doesn't make sense to me, and IBM seems to agree. Therefore the PMR.




--
Peter Hunkeler





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

Re: Z114 to z14 experience any ?

[Jake Anderson]

We are not in sysplex so I hope it should not be a concern ?

On Wed 11 Jul, 2018, 5:04 PM Parwez Hamid,  wrote:

> The old SAPR process been 'replaced' by the TDA. The SAPR Guide is no
> longer produced. Its just the Must Read doc and actually covers most of the
> H/W and OS planning.
>
> --
> 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: z/OS JCl vs. VSE JCL: VSAM files

[Steve Smith]

DISP=NEW or OLD is perfectly valid for VSAM and PDSEs.  PDSEs presumably
use some kind of hidden paging interface like LINEAR and ZFS do, but are
not VSAM.

sas

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

[Elardus Engelbrecht]

Vernooij, Kees (ITOPT1) - KLM wrote:

>What is in fact the problem with this job, that the SORTWK specification 
>should be changed from JCL to dynamic?

>It seems, that you try to provide the much varying workspace, where in fact, 
>the job should be able to get its space anyhow.

>What is the problem with specifying the historical 90% space consumption and 
>allow for 50 or 100% growth, in JCL?
>When needed, you must have the largest amount of space available, so why not 
>make it available to every run of the job? It is only temporary, 
>seconds/minutes/qtrs/hours, not permanent.

Ok, time for me to jump in (despite just now posted the note about a PMR):

Your questions are good questions!

Perhaps the OP should also put in the "estimate" on how big the input for all 
the sorting work is in other terms.

Something like this: Have REGION= and OPTION 
DYNSPC=512,SIZE=E9,MAINSIZE=MAX (which is working for my hungry sort 
jobs.)

This will help DFSORT to try to allocate enough pool of work datasets to play 
with.

This is what I mostly do, I specify really large SORTWKnn and/or really large 
dynamic sort space. YMMV.

Of course, you should check your SMS setup so you have lots of free space.

If you still can't resolve your sort, try splitting up your sort input and/or 
just do a subselection.

Groete / Greetings
Elardus Engelbrecht

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

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

[Vernooij, Kees (ITOPT1) - KLM]

What is in fact the problem with this job, that the SORTWK specification should 
be changed from JCL to dynamic?

It seems, that you try to provide the much varying workspace, where in fact, 
the job should be able to get its space anyhow.

What is the problem with specifying the historical 90% space consumption and 
allow for 50 or 100% growth, in JCL?
When needed, you must have the largest amount of space available, so why not 
make it available to every run of the job? It is only temporary, 
seconds/minutes/qtrs/hours, not permanent.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: 04 July, 2018 21:36
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Primary & secondary space values in DFSORT's dynamic work space
> allocation.
> 
> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that 

Re: Z114 to z14 experience any ?

[Parwez Hamid]

The old SAPR process been 'replaced' by the TDA. The SAPR Guide is no longer 
produced. Its just the Must Read doc and actually covers most of the H/W and OS 
planning.

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

AW: IEC614I Scratch

[Peter Hunkeler]

Someone posted the text of the IEC614I. Doesn't look like a scratch message to 
me.

Was initiates the deletion of the GDS? Roll-off due to LIMIT being reached? How 
is the GDG defined? Are the GDSs SMS managed?

--Peter Hunkeler


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

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

[Peter Hunkeler]

>BTW, I wrote a test program meanwhile and found that the manual and the 
>reality diverge. I'm pursuing this offline and will report back once I know 
>more.


I got a response from Kolusu. We're gonna open a PMR for this.

--
Peter Hunkeler



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

Re: IEC614I Scratch

[Mark Jacobs - Listserv]

One of the parmlb datasets. If you have command access, issue a D PARMLIB 
command for the list of datasets in use. You can also issue a D MPF command 
which should show the active list too.

Hervey Martinez wrote on 7/11/18 8:35 AM:

Hey Mark,


I normally are looking up parms. What parm library is this in? zos?


Hervey



From: IBM Mainframe Discussion List 
 on behalf of Mark Jacobs - 
Listserv 
Sent: Monday, July 9, 2018 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEC614I Scratch

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

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

[Hobart Spitz]

The JOL effort is commendable, but replacing JCL is about much more than a
nicer syntax or easy movement between foreground and background.

At the risk of repetition, other reasons are (1) to eliminate the
separation between scripting code and application code and (2) to interface
with other software/data (files, DB2, ISPF, etc.).

Resistance to replacing JCL comes from the fact that "everybody knows JCL"
(which they don't really).  Everybody (in the target audience) knows REXX,
if not directly, then because REXX has many well-know features of other
languages.  JCL resembles only mainframe assembler.

Add in PIPElines and you get a productivity and performance improvements
unlike any other option available.  Charles's example in REXX and PIPElines
might look like this.

   1. "pipe (end ?) ? < trans | v: validate | g: gate",
   2.   "? v: sort 10.10 | g:| u: update | >" GDG("payroll.master(+1)")",
   3.   "? <" GDG("payroll.master(0)") | u:"
   4.
   5. if RC = 0 then
   6. "submit job2"
   7. else
   8. "delete" GDG("payroll.master(0)")

I tried to stay true to Charles's example.  If you can to skip invalid
transactions, but still process valid ones (a reasonable approach), you can
eliminate the GATE and combine the first two streams.

GDG() is a function that I've previously written.

Note that zero intermediate files are needed, saving those I/O operations.

I haven't read the details of JOL, so I might be missing something.  I'm
happy to be educated.


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 11, 2018 at 6:40 AM, David Crayford  wrote:

> On 11/07/2018 7:19 AM, Clem Clarke wrote:
>
>> Don't know about that! I always think that IBM has some of the best
>> people and concepts.  Pity IBM didn't push PL/I instead od allowing C to
>> rule the world.
>>
>>
> They did, but something that's free will always be more attractive.
> Multics was originally written in PL/I but the UNIX devs didn't think it
> was suitable for operating systems.
>
> However, there's an interesting IBM lab in Perth that has some excellent
>> people. Not many people know about it.
>>
>
> Not any more! They all got the push when IBM recently cut their workforce.
> A few of them moved to HCL with the PD products. The rest of them are
> looking for work.
>
>
> --
> 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

[Hervey Martinez]

Hey Mark,


I normally are looking up parms. What parm library is this in? zos?


Hervey



From: IBM Mainframe Discussion List  on behalf of 
Mark Jacobs - Listserv 
Sent: Monday, July 9, 2018 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEC614I Scratch

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

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

Re: Z114 to z14 experience any ?

[Dana Mitchell]

We are currently on z114's  and will probably migrate to z14 zr1's,  and the 
coupling link situation is our biggest stumbling block.  Since there is no 
common coupling link available between z114-z14,  it will require us to move 
the entire plex at once,  not rolling onto new hardware, one LPAR at a time as 
we have in the past.

Dana
 
On Wed, 11 Jul 2018 01:15:15 -0700, Tom Brennan  
wrote:

>- ZR1 cannot use HCA coupling links, only the new ICA.

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

[David Crayford]

On 11/07/2018 7:19 AM, Clem Clarke wrote:
Don't know about that! I always think that IBM has some of the best 
people and concepts.  Pity IBM didn't push PL/I instead od allowing C 
to rule the world.




They did, but something that's free will always be more attractive. 
Multics was originally written in PL/I but the UNIX devs didn't think it 
was suitable for operating systems.


However, there's an interesting IBM lab in Perth that has some 
excellent people. Not many people know about it. 


Not any more! They all got the push when IBM recently cut their 
workforce. A few of them moved to HCL with the PD products. The rest of 
them are looking for work.


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

[R.S.]

Yes, that's true.
Fortunately ICF as other specialty engines always run at full speed.
That's also reason why one should not use older machines for CF.

BTW: Third CPC need not be very expensive. I'm neither IBM sales guy, 
nor "standalone CF evnagelist", but when you buy two CPCs with CP 
engines you pay for MIPS then for the frame. In such deal, adding 
another CPC with zero MIPS can be quite inexpensive when compared to 
"regular" CPC.


And regarding level of redundancy: it's obvious when you use spare wheel 
you don't have spare. It's the same with CF. AFAIK you can have up to 16 
CFs in a sysplex, but usually we protect against SINGLE failure, not 
coordinated series of failures. That's why we carry only one spare wheel 
in a car (typically).


Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-07-11 o 11:34, Richards, Robert B. pisze:

Just make sure that if you have a standalone CPC with CFs for that purpose that its 
engines are as fast as your other CPCs engines. I got into a performance problem 15 
years ago when a 9674 was kept around longer that it should have been. You are only 
as fast as your slowest .

Bob

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

Maybe it's illusory, but that is in David Raften document.
Obviously it's cheaper to have 2 CPCs than 3, but it is also cheaper to
have 1 CPC than 2.
The white paper clearly describes some structures as demanding duplexing
or third CPC with failure-isolated CF.




==


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

[ITschak Mugzach]

Speaking of replacing JCL, how about unisys WFL? It's a programming
language dedicated to job flows. BTW, I am happy with jcl...

ITschak

On Wed, Jul 11, 2018 at 12:09 PM Tony Thigpen  wrote:

> So where does JOL get all the other informatoin for the DD card? Is
> there some back-end database that has information for all the files that
> may be used?
>
> Tony Thigpen
>
> Clem Clarke wrote on 07/10/2018 08:33 PM:
> > Below is an example of Jol, and the equivalent JCL.
> >
> > Clem
> >
> > Simplified Jol Scripting Language for Z/OS, TSO, Linux and Windows
> >
> > Payroll: Job class C 1000 k;
> > Exec Validate Input.Trans, Trans.Action(+1); /* Validate Transations */
> > if Validate=0
> > then do;
> >  Sort transaction(+1) to Sorted.Trans.Actions(+1)
> >  Fields(10,10,CH,A);
> >  Exec Update Payroll.Master(0), Sorted.Trans.Action(+1),
> >  Payroll.Master(+1);
> >  If Update = 0
> >  then do;
> >  Catalog Payroll.Master(+1), Sorted.Trans.Action(+1);
> >  Submit Job2;
> >  end;
> > end;
> > else Stop 'Error in PAYROLL Job';
> >
> >
> > 
> >
> > Equivalent Existing Job Control Language
> >
> >
> > //PAYROLL   JOB  CLASS=C,REGION=1000K
> > //VALIDATE   EXEC PGM=VALIDATE
> > //SYSPRINT   DD   SYSOUT=*
> > //INTRANSDD   DSN=INPUT.TRANS,DISP=SHR
> > //OUTTRANS   DD   DSN=TRANS.ACTIONS(+1),DISP=(NEW,PASS),
> > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
> > //SPACE=(CYL,(10,10),RLSE),
> > //UNIT=SYSDA,VOL=SER=WORK01
> > //SORT   EXEC PGM=SORT,COND=(VALIDATE,NE,0)
> > //SYSOUT DD   SYSOUT=*
> > //SORTWK01   DD   UNIT=SYSDA,SPACE=(CYL,20)
> > //SORTWK02   DD   UNIT=SYSDA,SPACE=(CYL,20)
> > //SORTWK03   DD   UNIT=SYSDA,SPACE=(CYL,20)
> > //SORTIN DD   DSN=TRANS.ACTIONS(+1),DISP=(SHR,PASS)
> > //SORTOUTDD   DSN=SORTED.TRANS.ACTIONS(+1),
> > //DISP=(NEW,PASS),
> > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
> > //SPACE=(CYL,(10,10),RLSE),
> > //UNIT=SYSDA,VOL=SER=WORK01
> > //SYSIN  DD   *
> >  SORT FIELDS=(10,10,CH,A)
> > //UPDATE EXEC PGM=UPDATE,COND=(VALIDATE,NE,0)
> > //SYSPRINT   DD   SYSOUT=*
> > //MASTIN DD   DSN=PAYROLL.MASTER(0),DISP=SHR
> > //TRANS  DD   DSN=TRANS.ACTION(+1),DISP=(SHR,PASS)
> > //MASTOUTDD   DSN=PAYROLL.MASTER(+1),DISP=(NEW,PASS),
> > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
> > //SPACE=(CYL,(10,10),RLSE),
> > //UNIT=SYSDA,VOL=SER=WORK01
> > //CATLG  EXEC PGM=IEFBR14,COND=(UPDATE,NE,0)
> > //DUMMY1 DD   DSN=PAYROLL.MASTER(+1),DISP=(SHR,CATLG)
> > //DUMMY2 DD   DSN=SORTED.TRANS.ACTIONS(+1),
> > //DISP=(SHR,CATLG)
> > //SUBMIT EXEC PGM=IEBGENER,COND=(UPDATE,NE,0)
> > //SYSPRINT   DD   SYSOUT=*
> > //SYSUT1 DD   DSN=SUBMIT.LIBRARY(JOB2),DISP=SHR
> > //SYSUT2 DD   SYSOUT=(*,INTRDR)
> > //SYSIN  DD   DUMMY
> > //ERRMSG EXEC PGM=SHOWERR,COND=(VALIDATE,EQ,0),
> > //   PARM='Error in PAYROLL Job'
> >
> >
> >
> > 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.
> >>
> >> 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: REXX as JCL replacement

[Tony Thigpen]

So where does JOL get all the other informatoin for the DD card? Is 
there some back-end database that has information for all the files that 
may be used?


Tony Thigpen

Clem Clarke wrote on 07/10/2018 08:33 PM:

Below is an example of Jol, and the equivalent JCL.

Clem

Simplified Jol Scripting Language for Z/OS, TSO, Linux and Windows

Payroll: Job class C 1000 k;
Exec Validate Input.Trans, Trans.Action(+1); /* Validate Transations */
if Validate=0
then do;
     Sort transaction(+1) to Sorted.Trans.Actions(+1)
         Fields(10,10,CH,A);
     Exec Update Payroll.Master(0), Sorted.Trans.Action(+1),
         Payroll.Master(+1);
     If Update = 0
     then do;
         Catalog Payroll.Master(+1), Sorted.Trans.Action(+1);
         Submit Job2;
     end;
end;
else Stop 'Error in PAYROLL Job';




Equivalent Existing Job Control Language


//PAYROLL   JOB      CLASS=C,REGION=1000K
//VALIDATE   EXEC     PGM=VALIDATE
//SYSPRINT   DD       SYSOUT=*
//INTRANS    DD       DSN=INPUT.TRANS,DISP=SHR
//OUTTRANS   DD       DSN=TRANS.ACTIONS(+1),DISP=(NEW,PASS),
//        DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//        SPACE=(CYL,(10,10),RLSE),
//        UNIT=SYSDA,VOL=SER=WORK01
//SORT   EXEC     PGM=SORT,COND=(VALIDATE,NE,0)
//SYSOUT DD       SYSOUT=*
//SORTWK01   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTWK02   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTWK03   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTIN DD       DSN=TRANS.ACTIONS(+1),DISP=(SHR,PASS)
//SORTOUT    DD       DSN=SORTED.TRANS.ACTIONS(+1),
//        DISP=(NEW,PASS),
//        DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//        SPACE=(CYL,(10,10),RLSE),
//        UNIT=SYSDA,VOL=SER=WORK01
//SYSIN  DD   *
     SORT FIELDS=(10,10,CH,A)
//UPDATE EXEC     PGM=UPDATE,COND=(VALIDATE,NE,0)
//SYSPRINT   DD       SYSOUT=*
//MASTIN DD       DSN=PAYROLL.MASTER(0),DISP=SHR
//TRANS  DD       DSN=TRANS.ACTION(+1),DISP=(SHR,PASS)
//MASTOUT    DD       DSN=PAYROLL.MASTER(+1),DISP=(NEW,PASS),
//        DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//        SPACE=(CYL,(10,10),RLSE),
//        UNIT=SYSDA,VOL=SER=WORK01
//CATLG  EXEC     PGM=IEFBR14,COND=(UPDATE,NE,0)
//DUMMY1 DD       DSN=PAYROLL.MASTER(+1),DISP=(SHR,CATLG)
//DUMMY2 DD       DSN=SORTED.TRANS.ACTIONS(+1),
//            DISP=(SHR,CATLG)
//SUBMIT EXEC     PGM=IEBGENER,COND=(UPDATE,NE,0)
//SYSPRINT   DD       SYSOUT=*
//SYSUT1 DD       DSN=SUBMIT.LIBRARY(JOB2),DISP=SHR
//SYSUT2 DD       SYSOUT=(*,INTRDR)
//SYSIN  DD       DUMMY
//ERRMSG EXEC     PGM=SHOWERR,COND=(VALIDATE,EQ,0),
//   PARM='Error in PAYROLL Job'



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.


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




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