date:20201222

Re: Build and submit proc

2020-12-22 Thread Tom Brennan


Oh I think I've made more than my share of mistakes of the years :)

But yeah, you have to find something close and look out if //SYSUT2 
happens to be above //SYSUT1, or //FROM and //TO are not exactly what 
you think they are.


On 12/22/2020 3:01 PM, Seymour J Metz wrote:

That's OK if you understand what you're copying; it can be deadly if you don't.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Tuesday, December 22, 2020 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Build and submit proc

Whew!  Then I'm lucky I never really wrote any JCL - I always copy
something similar.  In fact, if JCL had DNA I bet most could be traced
back to a single IEBGENER job, formed in a tide pool eons ago.

On 12/22/2020 11:14 AM, Hobart Spitz wrote:

You can do it in batch REXX.

Stop being brain-dead and thinking about everything in terms of JCL.

I've don't write JCL anymore.

JCL causes brain-damage.


On Tuesday, December 22, 2020, Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:


I would build the JCL, and then FTP it with the filetype below.   That
will submit and run the job.

SITE FILEtype=JES NOJESGETBYDSN
put your.modified.jcl.


_
Dave Jousma
AVP | Director, Technology Engineering

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
Rapids, MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf
Of Fred Kaptein
Sent: Tuesday, December 22, 2020 12:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Build and submit proc

**CAUTION EXTERNAL EMAIL**

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

Hello,
I would like to build a JCL batch job called BACKUPS, that does the
following:
1) STEP01
  Create a JCL proc in MYLIB.PROCLIB(BKUP)
2) STEP02
  Execute the proc MYLIB.PROCLIB(BKUP)

My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was
built prior to submitting job BACKUPS.

Is there a way to do these two steps in one job and not two?

Thanks

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

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

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


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






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

Installing RHEL 8.3 in Native LPAR

2020-12-22 Thread Munif Sadek

I have been struggling to install RHEL 8.3 on a native HMC LPAR (Z14). My CPC 
is with multiple IFLs and I have configured couple of LPARs with Linux, 16 GB 
memory and with both Dedicated and non Dedicated IFLs but my Load from REMOTE 
MEDIA server to upload RHEL ISO (DVD image) hangs and times out after 55 
minutes, the LOAD function expire time. 

my FTP *nix server is work fine as Load function can easily find genric.ins 
from the mounted ISO image but hangs after that. DVD image is 6.3 GB and hence 
can not create a DVD for a direct DVD load on HMC.

Has anyone installed RHEL 8.3 successfully on a Native LPAR (no z/VM or KVM) 
and willing to help.

Thanks listers.
regards
Munif.

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

Re: Build and submit proc

2020-12-22 Thread Mike Schwab

Don't forget to compress the PDS frequently, or make it a PDSE.

Once we had hour long queues for a compile, so I wrote a CLIST to
execute the compile and link steps, took about 3 minutes.

On Tue, Dec 22, 2020 at 11:11 AM Fred Kaptein  wrote:
>
> Hello,
> I would like to build a JCL batch job called BACKUPS, that does the following:
> 1) STEP01
> Create a JCL proc in MYLIB.PROCLIB(BKUP)
> 2) STEP02
> Execute the proc MYLIB.PROCLIB(BKUP)
>
> My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was 
> built prior to submitting job BACKUPS.
>
> Is there a way to do these two steps in one job and not two?
>
> Thanks
>
> --
> 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: JCL divergence

2020-12-22 Thread Matt Hogstrom

BMC’s Ctrl M is another solution that does batch automation on Z and 
distributed as well as ESP from Broadcom.  Nothing really different on 
distributed environments versus mainframe apart from spool processing but those 
exist as well but not quite as well organized as on Z imho.

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

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

> On Dec 22, 2020, at 7:23 PM, Mike Hochee  wrote:
> 
> There exist a number of scheduling solutions available for LUW workloads, 
> IBM's Tivoli Workload Schedule is definitely among them... 
> https://www.ibm.com/support/pages/tivoli-workload-scheduler-version-851-3  
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of John McKown
> Sent: Tuesday, December 22, 2020 6:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL divergence
> 
> Caution! This message was sent from outside your organization.
> 
> On Tue, Dec 22, 2020 at 5:26 PM Gibney, Dave  wrote:
> 
>> WindowsJob...Huh
>> 
> 
> Right. I am so ignorant, perhaps the Windows (and Linux?) world doesn't even 
> have any unattended scheduled activities. I know that there is a "Windows 
> Scheduler" that can run a batch file (MSDOS .bat) automatically at a given 
> time or when a particular user does a "log on" (perhaps akin to a TSO logon 
> proc).
> 
> If the above is true (no automated unattended work), I wonder how companies 
> do {month,quarter,year}-end processing to generate reports to send to 
> appropriate governmental bodies. Or even, as in my employer, to policyholders.
> 
> 
> 
>> 
>>> Hum, how do the Windows experts "restart" a "job" that fails? I 
>>> really don't now.
>>> 
>> 
>> 
> 
> --
> 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: JCL divergence

2020-12-22 Thread Gibney, Dave

Somewhat tongue in cheek. Actually, we used the CA-7 agent and Control-M 
Enterprise manager. Once z/OS is shutdown, they will continue to use Control-M.

The robustness of the scripts substituting for jobs leaves some to be desired. 
But, I suppose improvement will occur over time.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gibney, Dave
> Sent: Tuesday, December 22, 2020 3:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JCL divergence
> 
> WindowsJob...Huh
> 
> > Hum, how do the Windows experts "restart" a "job" that fails? I really
> > don't now.
> >
> > --
> > 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: JCL divergence

2020-12-22 Thread Steve Horein

AutoSys?
https://www.broadcom.com/products/software/automation/autosys

On Tue, Dec 22, 2020 at 5:57 PM John McKown 
wrote:

> On Tue, Dec 22, 2020 at 5:49 PM Seymour J Metz  wrote:
>
> > https://en.wikipedia.org/wiki/Cron
> >
> >
> I use CRON a fair amount on Linux at home. And on z/OS at work, for
> "personal scheduling". And there's the equivalent "Windows Task Scheduler"
> on Windows. But I wonder if any business uses them for things that we use
> CA-7 for. IIRC, CA had a Windows product where you'd put an "agent" on a
> Windows system and CA-7 could schedule work there. We actually tried to use
> it. But it never caught on in the Windows world at my company.
>
> There is this:
>
> https://docs.microsoft.com/en-us/sql/reporting-services/install-windows/configure-the-unattended-execution-account-ssrs-configuration-manager?view=sql-server-ver15
>
> But I'm getting too far off topic.
>
>
>
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of John McKown [john.archie.mck...@gmail.com]
> > Sent: Tuesday, December 22, 2020 6:35 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: JCL divergence
> >
> > On Tue, Dec 22, 2020 at 5:26 PM Gibney, Dave  wrote:
> >
> > > WindowsJob...Huh
> > >
> >
> > Right. I am so ignorant, perhaps the Windows (and Linux?) world doesn't
> > even have any unattended scheduled activities. I know that there is a
> > "Windows Scheduler" that can run a batch file (MSDOS .bat) automatically
> at
> > a given time or when a particular user does a "log on" (perhaps akin to a
> > TSO logon proc).
> >
> > If the above is true (no automated unattended work), I wonder how
> companies
> > do {month,quarter,year}-end processing to generate reports to send to
> > appropriate governmental bodies. Or even, as in my employer, to
> > policyholders.
> >
> >
> >
> > >
> > > > Hum, how do the Windows experts "restart" a "job" that fails? I
> really
> > > > don't now.
> > > >
> > >
> > >
> >
> > --
> > 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: JCL divergence

2020-12-22 Thread Mike Hochee

There exist a number of scheduling solutions available for LUW workloads, IBM's 
Tivoli Workload Schedule is definitely among them... 
https://www.ibm.com/support/pages/tivoli-workload-scheduler-version-851-3  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, December 22, 2020 6:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL divergence

Caution! This message was sent from outside your organization.

On Tue, Dec 22, 2020 at 5:26 PM Gibney, Dave  wrote:

> WindowsJob...Huh
>

Right. I am so ignorant, perhaps the Windows (and Linux?) world doesn't even 
have any unattended scheduled activities. I know that there is a "Windows 
Scheduler" that can run a batch file (MSDOS .bat) automatically at a given time 
or when a particular user does a "log on" (perhaps akin to a TSO logon proc).

If the above is true (no automated unattended work), I wonder how companies do 
{month,quarter,year}-end processing to generate reports to send to appropriate 
governmental bodies. Or even, as in my employer, to policyholders.

>
> > Hum, how do the Windows experts "restart" a "job" that fails? I 
> > really don't now.
> >
>
>

--
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: Build and submit proc

2020-12-22 Thread Seymour J Metz

The existing scheduling software relies on the existing JCL processing; deploy 
a new paradigm and everybody needs to start from scratch.

Checkpoint/restart used to be common for large number crunching jobs and large 
tape jobs; how many production jobs these days match either profile? Most shops 
I've seen in the last few decades are doing some sort of random access 
processing. Transaction oriented restart seems a lot more relevant for modern 
workloads.

I've occasionally used step restart, but as with C/R, an awful lot of work 
doesn't match its use case. You really don't want to wind up running some of 
the transactions twice.

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

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
John McKown [john.archie.mck...@gmail.com]
Sent: Tuesday, December 22, 2020 7:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Build and submit proc

On Tue, Dec 22, 2020 at 5:56 PM Seymour J Metz  wrote:

> > IMO, you could replace all your JCL with REXX code.
>
> You'd have a hard time with scheduling if you tried that.
>
> > But then the programmer needs to be a REXX expert
>
> Why? Most users aren't JCL experts. Besides, in some ways REXX is simpler.
>

I agree, but CA-7 & CA-11 do the "hard lifting" for the staff WRT to
scheduling & restarting. Hopefully after a programmer has fixed whatever
caused the initial problem.

>
> > Hum, how do the Windows experts "restart" a "job" that fails?
>
> How does z/OS? There are stringent limitations on checkpoint restart. Step
> restart is less constrained but not always appropriate.
>

Does anybody actually use that? In 40+ years, I've never seen  it used.
Perhaps because I've never been in a really large shop. I was  thinking of
CA-11 which tracks a job & allows restarting easily by a production control
type person (likely not a programmer).

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

--
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: Build and submit proc

2020-12-22 Thread John McKown

On Tue, Dec 22, 2020 at 5:56 PM Seymour J Metz  wrote:

> > IMO, you could replace all your JCL with REXX code.
>
> You'd have a hard time with scheduling if you tried that.
>
> > But then the programmer needs to be a REXX expert
>
> Why? Most users aren't JCL experts. Besides, in some ways REXX is simpler.
>

I agree, but CA-7 & CA-11 do the "hard lifting" for the staff WRT to
scheduling & restarting. Hopefully after a programmer has fixed whatever
caused the initial problem.

>
> > Hum, how do the Windows experts "restart" a "job" that fails?
>
> How does z/OS? There are stringent limitations on checkpoint restart. Step
> restart is less constrained but not always appropriate.
>

Does anybody actually use that? In 40+ years, I've never seen  it used.
Perhaps because I've never been in a really large shop. I was  thinking of
CA-11 which tracks a job & allows restarting easily by a production control
type person (likely not a programmer).

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

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

Re: JCL divergence

2020-12-22 Thread John McKown

On Tue, Dec 22, 2020 at 5:49 PM Seymour J Metz  wrote:

> https://en.wikipedia.org/wiki/Cron
>
>
I use CRON a fair amount on Linux at home. And on z/OS at work, for
"personal scheduling". And there's the equivalent "Windows Task Scheduler"
on Windows. But I wonder if any business uses them for things that we use
CA-7 for. IIRC, CA had a Windows product where you'd put an "agent" on a
Windows system and CA-7 could schedule work there. We actually tried to use
it. But it never caught on in the Windows world at my company.

There is this:
https://docs.microsoft.com/en-us/sql/reporting-services/install-windows/configure-the-unattended-execution-account-ssrs-configuration-manager?view=sql-server-ver15

But I'm getting too far off topic.



>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of John McKown [john.archie.mck...@gmail.com]
> Sent: Tuesday, December 22, 2020 6:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JCL divergence
>
> On Tue, Dec 22, 2020 at 5:26 PM Gibney, Dave  wrote:
>
> > WindowsJob...Huh
> >
>
> Right. I am so ignorant, perhaps the Windows (and Linux?) world doesn't
> even have any unattended scheduled activities. I know that there is a
> "Windows Scheduler" that can run a batch file (MSDOS .bat) automatically at
> a given time or when a particular user does a "log on" (perhaps akin to a
> TSO logon proc).
>
> If the above is true (no automated unattended work), I wonder how companies
> do {month,quarter,year}-end processing to generate reports to send to
> appropriate governmental bodies. Or even, as in my employer, to
> policyholders.
>
>
>
> >
> > > Hum, how do the Windows experts "restart" a "job" that fails? I really
> > > don't now.
> > >
> >
> >
>
> --
> 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: Build and submit proc

2020-12-22 Thread Seymour J Metz

> IMO, you could replace all your JCL with REXX code.

You'd have a hard time with scheduling if you tried that.

> But then the programmer needs to be a REXX expert

Why? Most users aren't JCL experts. Besides, in some ways REXX is simpler.

> Hum, how do the Windows experts "restart" a "job" that fails?

How does z/OS? There are stringent limitations on checkpoint restart. Step 
restart is less constrained but not always appropriate.

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

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
John McKown [john.archie.mck...@gmail.com]
Sent: Tuesday, December 22, 2020 6:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Build and submit proc

On Tue, Dec 22, 2020 at 2:44 PM Wayne Bickerdike  wrote:

> Many moons ago, when I was a trainee programmer I asked my senior
> programmer why IBM couldn't just get rid of JCL. He laughed. I was serious,
> still am 45 years later.
>
>
Why JCL even after  all this time?  Cost. Let's suppose IBM  wanted  to do
this. First, they'd need to design a new way to do batch work. That means
something  like JCL2 or AJCL (Advanced JCL). Now, that  needs to be
converted into internal text. Hum? That means either an entirely new
internal text, or more "types" (like adding  new instructions  to an ISA?).
But then the initiator needs to be updated. And, if new functions, that
means new things in the SWA (which I guess in an in-core version of
internal text). All of this takes time and money. So, how much are you (or
your company/employer) willing to pay for this? Perhaps it should be a
Program Product?

Oh, and last but not least. Will all Broadcom (nee CA) update CA-11 and
CA-7 (perhaps others) to support this new facility?  I know in many shops,
if  you took away CA-11, the production control staff would likely be
unable to do restarts correctly. Unless, of course, AJCL included an
automated way to restart a job. But that's even more cost. And would likely
really upset Broadcom.

IMO, you could replace all your JCL with REXX code. But then the programmer
needs to be a REXX expert. And the restart logic must be coded in every
REXX program, {shudder}

Hum, how do the Windows experts "restart" a "job" that fails? I really
don't now.

--
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: JCL divergence

2020-12-22 Thread Seymour J Metz

https://en.wikipedia.org/wiki/Cron

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

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
John McKown [john.archie.mck...@gmail.com]
Sent: Tuesday, December 22, 2020 6:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL divergence

On Tue, Dec 22, 2020 at 5:26 PM Gibney, Dave  wrote:

> WindowsJob...Huh
>

Right. I am so ignorant, perhaps the Windows (and Linux?) world doesn't
even have any unattended scheduled activities. I know that there is a
"Windows Scheduler" that can run a batch file (MSDOS .bat) automatically at
a given time or when a particular user does a "log on" (perhaps akin to a
TSO logon proc).

If the above is true (no automated unattended work), I wonder how companies
do {month,quarter,year}-end processing to generate reports to send to
appropriate governmental bodies. Or even, as in my employer, to
policyholders.

>
> > Hum, how do the Windows experts "restart" a "job" that fails? I really
> > don't now.
> >
>
>

--
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: JCL divergence

2020-12-22 Thread John McKown

On Tue, Dec 22, 2020 at 5:26 PM Gibney, Dave  wrote:

> WindowsJob...Huh
>

Right. I am so ignorant, perhaps the Windows (and Linux?) world doesn't
even have any unattended scheduled activities. I know that there is a
"Windows Scheduler" that can run a batch file (MSDOS .bat) automatically at
a given time or when a particular user does a "log on" (perhaps akin to a
TSO logon proc).

If the above is true (no automated unattended work), I wonder how companies
do {month,quarter,year}-end processing to generate reports to send to
appropriate governmental bodies. Or even, as in my employer, to
policyholders.

>
> > Hum, how do the Windows experts "restart" a "job" that fails? I really
> > don't now.
> >
>
>

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

JCL divergence

2020-12-22 Thread Gibney, Dave

WindowsJob...Huh

> Hum, how do the Windows experts "restart" a "job" that fails? I really
> don't now.
> 
> --
> 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: Build and submit proc

2020-12-22 Thread John McKown

On Tue, Dec 22, 2020 at 2:44 PM Wayne Bickerdike  wrote:

> Many moons ago, when I was a trainee programmer I asked my senior
> programmer why IBM couldn't just get rid of JCL. He laughed. I was serious,
> still am 45 years later.
>
>
Why JCL even after  all this time?  Cost. Let's suppose IBM  wanted  to do
this. First, they'd need to design a new way to do batch work. That means
something  like JCL2 or AJCL (Advanced JCL). Now, that  needs to be
converted into internal text. Hum? That means either an entirely new
internal text, or more "types" (like adding  new instructions  to an ISA?).
But then the initiator needs to be updated. And, if new functions, that
means new things in the SWA (which I guess in an in-core version of
internal text). All of this takes time and money. So, how much are you (or
your company/employer) willing to pay for this? Perhaps it should be a
Program Product?

Oh, and last but not least. Will all Broadcom (nee CA) update CA-11 and
CA-7 (perhaps others) to support this new facility?  I know in many shops,
if  you took away CA-11, the production control staff would likely be
unable to do restarts correctly. Unless, of course, AJCL included an
automated way to restart a job. But that's even more cost. And would likely
really upset Broadcom.

IMO, you could replace all your JCL with REXX code. But then the programmer
needs to be a REXX expert. And the restart logic must be coded in every
REXX program, {shudder}

Hum, how do the Windows experts "restart" a "job" that fails? I really
don't now.

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

Re: Build and submit proc

2020-12-22 Thread Hobart Spitz

Ignoring the wrong and/or irrelevant comments, anyone who is having trouble
running REXX, TSO, or ISPF in batch, please write to me directly.  Chances
are, I've been there and done that.  (See below.)

To get you started

   1. Create a JCL PROC to start TSO in batch:  You can do one of these.
  - If you can execute your logon proc in batch, this step is mostly
  done.
  - or, under SDSF look at your TSO session or a timed out one.  Do an
  SE on the JCL; ((10, c all xx '//', etc. and you have JCL that
mimics your
  logon proc.
  -
  - or, start with // EXEC PGM=IJKEFT01.  Include DDs for SYSTSPRT and
  SYSTSIN,
 - use DDLIST with what you want in your batch environment, and
 type SAVE.  That will generate a CLIST with all your allocations.
 - Execute the generated CLIST with PARM= or from SYSTSIN.
  2. Allocate or DD ISPPROF to a UNIT VIO, CYL SPACE 1,1,1.  Model the
   DCB after your own profile dataset.
   3. Use ISPLOG DD SYSOUT=* or ALLOCATE DD(ISPLOG) DATA(*).  IIRC, the DCB
   is RECFm=VA, LRECEL=137.  Check youR ISPLOGn.LIST dataset.
   4. Create a REXX exec to start ISPF in batch.  I always do this so I
   don't have to worry about what needs ISPF or not.  See my previous work on
   the very rare ISPSPROF ENQ and the very common getting the return code to
   the JCL level with ZISPFRC.
   5. Write a REXX EXEC to wrap any TSO command in JCL to invoke the above
   (1 and 4), adding a JOB card and anything else you need.  Since the early
   1990s, I've used the name SPAWN, as it does what SPAWN on other platforms
   does.
   6. Arrange for your "spawn" to take an argument which it adds to the job
   and for that argument to be passed to the EXEC from #5 above.
   7. (Optional) To make your "spawn" really robust, have it add any stack
   contents to the end of the job.  This will let you add any DDs for datasets
   that need deadlock ENQing protection, or anything else.

This should get you started.

Now, anytime you want to execute a TSO command, including REXX EXECs, in
batch use:

   - [TSO] %Spawn %myrexxex myarg..."
   - or from REXX:  "%Spawn %myrexex myargs..." or call Spawn "%myrexex
   myargs..."

It's not exactly trivial to do it right.  It is worth doing.

If you want to have some real fun, try emulating JCL in the foreground.
*-D  I've done 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 in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.


On Tue, Dec 22, 2020 at 3:33 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Dec 2020 15:05:47 -0600, Hobart Spitz wrote:
> >
> >Still not enough?  Write (or get your favorite assembler programmer to
> >write) a CMS SLEEP like program.  There might be one on a CBT tape or on
> >the web.
> >
> Assembler!?  CBT tape!?  What rock have you been under for the few
> decades that bog standard OS/390 Rexx has had:
> address SYSCALL 'sleep' 
>
> >99% of what JCL does for you can be done in REXX.  99% of what you can do
> >with REXX *cannot* be done in JCL. Anyone who thinks otherwise is just
> >wrong or is too lazy to do a little extra work that saves a lot of work
> >later.  Work smart, not hard.
> >
> I settled on a synthesis: code allocations, the JCL 1% as JCL DD statements
> and the 99% heavy lifting in IRXJCL Rexx or IKJEFT01 Rexx. I wash my hands
> after writing the JCL.
>
> Mr. Natural sez, Use the right tool for the job.
>
> -- 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: Build and submit proc

2020-12-22 Thread Seymour J Metz

That's OK if you understand what you're copying; it can be deadly if you don't.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Tuesday, December 22, 2020 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Build and submit proc

Whew!  Then I'm lucky I never really wrote any JCL - I always copy
something similar.  In fact, if JCL had DNA I bet most could be traced
back to a single IEBGENER job, formed in a tide pool eons ago.

On 12/22/2020 11:14 AM, Hobart Spitz wrote:
> You can do it in batch REXX.
>
> Stop being brain-dead and thinking about everything in terms of JCL.
>
> I've don't write JCL anymore.
>
> JCL causes brain-damage.
>
>
> On Tuesday, December 22, 2020, Jousma, David <
> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
>> I would build the JCL, and then FTP it with the filetype below.   That
>> will submit and run the job.
>>
>> SITE FILEtype=JES NOJESGETBYDSN
>> put your.modified.jcl.
>>
>> 
>> _
>> Dave Jousma
>> AVP | Director, Technology Engineering
>>
>> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
>> Rapids, MI 49546
>> 616.653.8429  |  fax: 616.653.2717
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf
>> Of Fred Kaptein
>> Sent: Tuesday, December 22, 2020 12:11 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Build and submit proc
>>
>> **CAUTION EXTERNAL EMAIL**
>>
>> **DO NOT open attachments or click on links from unknown senders or
>> unexpected emails**
>>
>> Hello,
>> I would like to build a JCL batch job called BACKUPS, that does the
>> following:
>> 1) STEP01
>>  Create a JCL proc in MYLIB.PROCLIB(BKUP)
>> 2) STEP02
>>  Execute the proc MYLIB.PROCLIB(BKUP)
>>
>> My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was
>> built prior to submitting job BACKUPS.
>>
>> Is there a way to do these two steps in one job and not two?
>>
>> Thanks
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send email
>> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
>> EXTERNAL EMAIL**
>>
>> **DO NOT open attachments or click on links from unknown senders or
>> unexpected emails**
>>
>> This e-mail transmission contains information that is confidential and may
>> be privileged.   It is intended only for the addressee(s) named above. If
>> you receive this e-mail in error, please do not read, copy or disseminate
>> it in any manner. If you are not the intended recipient, any disclosure,
>> copying, distribution or use of the contents of this information is
>> prohibited. Please reply to the message immediately by informing the sender
>> that the message was misdirected. After replying, please erase it from your
>> computer system. Your assistance in correcting this error is appreciated.
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>

--
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: Build and submit proc

2020-12-22 Thread Seymour J Metz

> This was and iis me being nice,

What are you smoking? No maater how you slice it, claiming "brain dead" is not 
being nice.

> People need to use their brains.

Yes, you should

> > JCL and the Initiator provide protection against ENQ deadlock
> > not available with Rexx.

> False:  

What the voices in your head said may be false, but what he actually wrote is 
true.

> TSO alloc or sysdsn() can protect against most situations.

ObRaven That in no way contradicts what he actually wrote.

Snap quiz: describe at least one failure mode of your suggested solution.

> CMS SLEEP

Checks calendar. Yep, it's 2020 - or do you hate Euxix so much that you don't 
have a UID?

Your hammer is no good; no matter how I try it won't turn the screw.

"When the only tool you have is a pipe, everything looks like a filter."

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

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Hobart Spitz [orexx...@gmail.com]
Sent: Tuesday, December 22, 2020 4:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Build and submit proc

On Tue, Dec 22, 2020 at 2:11 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Dec 2020 13:14:07 -0600, Hobart Spitz wrote:
>
> >You can do it in batch REXX.
> >
> >Stop being brain-dead and thinking about everything in terms of JCL.
> >
> >I've don't write JCL anymore.
> >
> >JCL causes brain-damage.
> >
> Be nice, or at least stay on-topic and ad-rem, not ad-hominem.
>

This was and iis me being nice, on-topic, etc.  People need to use their
brains.

>
> JCL and the Initiator provide protection against ENQ deadlock
> not available with Rexx.
>

False:  TSO alloc or sysdsn() can protect against most situations.

One simple, more general, solution is to do all critial allocations up
front.  If any fail, free all, wait a bit, and retry.

There are many alternatives,depending on the requirement.  E.g., If a
dataset is not available, skip it and do it later.

Still not enough?  Write (or get your favorite assembler programmer to
write) a CMS SLEEP like program.  There might be one on a CBT tape or on
the web.

99% of what JCL does for you can be done in REXX.  99% of what you can do
with REXX *cannot* be done in JCL. Anyone who thinks otherwise is just
wrong or is too lazy to do a little extra work that saves a lot of work
later.  Work smart, not hard.

>
>
> >On Tuesday, December 22, 2020, Jousma, David wrote:
> >
> >> I would build the JCL, and then FTP it with the filetype below.   That
> >> will submit and run the job.
> >>
> Why is this preferable to just writing directly, or via IEBGENER to INTRDR?
>
> >> SITE FILEtype=JES NOJESGETBYDSN
> >> put your.modified.jcl.
>
> -- 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

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

Re: Build and submit proc

2020-12-22 Thread Paul Gilmartin

On Tue, 22 Dec 2020 15:05:47 -0600, Hobart Spitz wrote:
>
>Still not enough?  Write (or get your favorite assembler programmer to
>write) a CMS SLEEP like program.  There might be one on a CBT tape or on
>the web.
> 
Assembler!?  CBT tape!?  What rock have you been under for the few
decades that bog standard OS/390 Rexx has had:
address SYSCALL 'sleep' 

>99% of what JCL does for you can be done in REXX.  99% of what you can do
>with REXX *cannot* be done in JCL. Anyone who thinks otherwise is just
>wrong or is too lazy to do a little extra work that saves a lot of work
>later.  Work smart, not hard.
>
I settled on a synthesis: code allocations, the JCL 1% as JCL DD statements
and the 99% heavy lifting in IRXJCL Rexx or IKJEFT01 Rexx. I wash my hands
after writing the JCL.

Mr. Natural sez, Use the right tool for the job.

-- gil

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

Re: Build and submit proc

2020-12-22 Thread Jesse 1 Robinson

The overlooked link in evolution. 

.
.
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  On Behalf Of Tom 
Brennan
Sent: Tuesday, December 22, 2020 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Build and submit proc

*** EXTERNAL EMAIL - Use caution when opening links or attachments ***

Whew!  Then I'm lucky I never really wrote any JCL - I always copy something 
similar.  In fact, if JCL had DNA I bet most could be traced back to a single 
IEBGENER job, formed in a tide pool eons ago.

On 12/22/2020 11:14 AM, Hobart Spitz wrote:
> You can do it in batch REXX.
>
> Stop being brain-dead and thinking about everything in terms of JCL.
>
> I've don't write JCL anymore.
>
> JCL causes brain-damage.
>
>
> On Tuesday, December 22, 2020, Jousma, David < 
> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
>> I would build the JCL, and then FTP it with the filetype below.   That
>> will submit and run the job.
>>
>> SITE FILEtype=JES NOJESGETBYDSN
>> put your.modified.jcl.
>>
>> 
>> _
>> Dave Jousma
>> AVP | Director, Technology Engineering
>>
>> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
>> Rapids, MI 49546
>> 616.653.8429  |  fax: 616.653.2717
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Fred Kaptein
>> Sent: Tuesday, December 22, 2020 12:11 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Build and submit proc
>>
>> **CAUTION EXTERNAL EMAIL**
>>
>> **DO NOT open attachments or click on links from unknown senders or 
>> unexpected emails**
>>
>> Hello,
>> I would like to build a JCL batch job called BACKUPS, that does the
>> following:
>> 1) STEP01
>>  Create a JCL proc in MYLIB.PROCLIB(BKUP)
>> 2) STEP02
>>  Execute the proc MYLIB.PROCLIB(BKUP)
>>
>> My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) 
>> that was built prior to submitting job BACKUPS.
>>
>> Is there a way to do these two steps in one job and not two?
>>
>> Thanks
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO 
>> IBM-MAIN **CAUTION EXTERNAL EMAIL**
>>
>> **DO NOT open attachments or click on links from unknown senders or 
>> unexpected emails**
>>
>> This e-mail transmission contains information that is confidential and may
>> be privileged.   It is intended only for the addressee(s) named above. If
>> you receive this e-mail in error, please do not read, copy or 
>> disseminate it in any manner. If you are not the intended recipient, 
>> any disclosure, copying, distribution or use of the contents of this 
>> information is prohibited. Please reply to the message immediately by 
>> informing the sender that the message was misdirected. After 
>> replying, please erase it from your computer system. Your assistance in 
>> correcting this error is appreciated.
>>
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO 
>> IBM-MAIN
>>
>
>

--
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: Build and submit proc

2020-12-22 Thread Gibney, Dave

There is the matter of MSTJCLxx  :)

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Wayne Bickerdike
> Sent: Tuesday, December 22, 2020 12:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Build and submit proc
> 
> Many moons ago, when I was a trainee programmer I asked my senior
> programmer why IBM couldn't just get rid of JCL. He laughed. I was serious,
> still am 45 years later.
> 
> 
> 
> On Wed, Dec 23, 2020 at 7:25 AM Tom Brennan
> 
> wrote:
> 
> > Whew!  Then I'm lucky I never really wrote any JCL - I always copy
> > something similar.  In fact, if JCL had DNA I bet most could be traced
> > back to a single IEBGENER job, formed in a tide pool eons ago.
> >
> > On 12/22/2020 11:14 AM, Hobart Spitz wrote:
> > > You can do it in batch REXX.
> > >
> > > Stop being brain-dead and thinking about everything in terms of JCL.
> > >
> > > I've don't write JCL anymore.
> > >
> > > JCL causes brain-damage.
> > >
> > >
> > > On Tuesday, December 22, 2020, Jousma, David <
> > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > >> I would build the JCL, and then FTP it with the filetype below.   That
> > >> will submit and run the job.
> > >>
> > >> SITE FILEtype=JES NOJESGETBYDSN
> > >> put your.modified.jcl.
> > >>
> > >>
> __
> __
> > >> _
> > >> Dave Jousma
> > >> AVP | Director, Technology Engineering
> > >>
> > >> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > >> Rapids, MI 49546
> > >> 616.653.8429  |  fax: 616.653.2717
> > >>
> > >>
> > >> -Original Message-
> > >> From: IBM Mainframe Discussion List 
> On
> > Behalf
> > >> Of Fred Kaptein
> > >> Sent: Tuesday, December 22, 2020 12:11 PM
> > >> To: IBM-MAIN@LISTSERV.UA.EDU
> > >> Subject: Build and submit proc
> > >>
> > >> **CAUTION EXTERNAL EMAIL**
> > >>
> > >> **DO NOT open attachments or click on links from unknown senders or
> > >> unexpected emails**
> > >>
> > >> Hello,
> > >> I would like to build a JCL batch job called BACKUPS, that does the
> > >> following:
> > >> 1) STEP01
> > >>  Create a JCL proc in MYLIB.PROCLIB(BKUP)
> > >> 2) STEP02
> > >>  Execute the proc MYLIB.PROCLIB(BKUP)
> > >>
> > >> My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that
> > was
> > >> built prior to submitting job BACKUPS.
> > >>
> > >> Is there a way to do these two steps in one job and not two?
> > >>
> > >> Thanks
> > >>
> > >> --
> > >> For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email
> > >> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> **CAUTION
> > >> EXTERNAL EMAIL**
> > >>
> > >> **DO NOT open attachments or click on links from unknown senders or
> > >> unexpected emails**
> > >>
> > >> This e-mail transmission contains information that is confidential and
> > may
> > >> be privileged.   It is intended only for the addressee(s) named above.
> > If
> > >> you receive this e-mail in error, please do not read, copy or
> > disseminate
> > >> it in any manner. If you are not the intended recipient, any disclosure,
> > >> copying, distribution or use of the contents of this information is
> > >> prohibited. Please reply to the message immediately by informing the
> > sender
> > >> that the message was misdirected. After replying, please erase it from
> > your
> > >> computer system. Your assistance in correcting this error is
> > appreciated.
> > >>
> > >>
> > >> --
> > >> For IBM-MAIN subscribe / signoff / archive access instructions,
> > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN
> > >>
> > >
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> 
> 
> --
> Wayne V. Bickerdike
> 
> --
> 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: Build and submit proc

2020-12-22 Thread Hobart Spitz

On Tue, Dec 22, 2020 at 2:11 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Dec 2020 13:14:07 -0600, Hobart Spitz wrote:
>
> >You can do it in batch REXX.
> >
> >Stop being brain-dead and thinking about everything in terms of JCL.
> >
> >I've don't write JCL anymore.
> >
> >JCL causes brain-damage.
> >
> Be nice, or at least stay on-topic and ad-rem, not ad-hominem.
>

This was and iis me being nice, on-topic, etc.  People need to use their
brains.

>
> JCL and the Initiator provide protection against ENQ deadlock
> not available with Rexx.
>

False:  TSO alloc or sysdsn() can protect against most situations.

One simple, more general, solution is to do all critial allocations up
front.  If any fail, free all, wait a bit, and retry.

There are many alternatives,depending on the requirement.  E.g., If a
dataset is not available, skip it and do it later.

Still not enough?  Write (or get your favorite assembler programmer to
write) a CMS SLEEP like program.  There might be one on a CBT tape or on
the web.

99% of what JCL does for you can be done in REXX.  99% of what you can do
with REXX *cannot* be done in JCL. Anyone who thinks otherwise is just
wrong or is too lazy to do a little extra work that saves a lot of work
later.  Work smart, not hard.

>
>
> >On Tuesday, December 22, 2020, Jousma, David wrote:
> >
> >> I would build the JCL, and then FTP it with the filetype below.   That
> >> will submit and run the job.
> >>
> Why is this preferable to just writing directly, or via IEBGENER to INTRDR?
>
> >> SITE FILEtype=JES NOJESGETBYDSN
> >> put your.modified.jcl.
>
> -- 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: Build and submit proc

2020-12-22 Thread Paul Gilmartin

On Wed, 23 Dec 2020 07:43:24 +1100, Wayne Bickerdike  wrote:

>Many moons ago, when I was a trainee programmer I asked my senior
>programmer why IBM couldn't just get rid of JCL. He laughed. I was serious,
>still am 45 years later.
> 
How do you solve the ENQ deadlock problem?  Telephone the sysop and
ask that the other guy be cancelled.

You need a language that performs multiple ENQs en masse.  Your design
is graded C- if the programmer needs to mention any DSN more than once.

It's been a while since JOL has been touted here as an alternative.
Perhaps Clement Clarke is no longer a contributor.

-- gil

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

Re: Build and submit proc

2020-12-22 Thread Wayne Bickerdike

Many moons ago, when I was a trainee programmer I asked my senior
programmer why IBM couldn't just get rid of JCL. He laughed. I was serious,
still am 45 years later.



On Wed, Dec 23, 2020 at 7:25 AM Tom Brennan 
wrote:

> Whew!  Then I'm lucky I never really wrote any JCL - I always copy
> something similar.  In fact, if JCL had DNA I bet most could be traced
> back to a single IEBGENER job, formed in a tide pool eons ago.
>
> On 12/22/2020 11:14 AM, Hobart Spitz wrote:
> > You can do it in batch REXX.
> >
> > Stop being brain-dead and thinking about everything in terms of JCL.
> >
> > I've don't write JCL anymore.
> >
> > JCL causes brain-damage.
> >
> >
> > On Tuesday, December 22, 2020, Jousma, David <
> > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> I would build the JCL, and then FTP it with the filetype below.   That
> >> will submit and run the job.
> >>
> >> SITE FILEtype=JES NOJESGETBYDSN
> >> put your.modified.jcl.
> >>
> >> 
> >> _
> >> Dave Jousma
> >> AVP | Director, Technology Engineering
> >>
> >> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> >> Rapids, MI 49546
> >> 616.653.8429  |  fax: 616.653.2717
> >>
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> Behalf
> >> Of Fred Kaptein
> >> Sent: Tuesday, December 22, 2020 12:11 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Build and submit proc
> >>
> >> **CAUTION EXTERNAL EMAIL**
> >>
> >> **DO NOT open attachments or click on links from unknown senders or
> >> unexpected emails**
> >>
> >> Hello,
> >> I would like to build a JCL batch job called BACKUPS, that does the
> >> following:
> >> 1) STEP01
> >>  Create a JCL proc in MYLIB.PROCLIB(BKUP)
> >> 2) STEP02
> >>  Execute the proc MYLIB.PROCLIB(BKUP)
> >>
> >> My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that
> was
> >> built prior to submitting job BACKUPS.
> >>
> >> Is there a way to do these two steps in one job and not two?
> >>
> >> Thanks
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email
> >> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
> >> EXTERNAL EMAIL**
> >>
> >> **DO NOT open attachments or click on links from unknown senders or
> >> unexpected emails**
> >>
> >> This e-mail transmission contains information that is confidential and
> may
> >> be privileged.   It is intended only for the addressee(s) named above.
> If
> >> you receive this e-mail in error, please do not read, copy or
> disseminate
> >> it in any manner. If you are not the intended recipient, any disclosure,
> >> copying, distribution or use of the contents of this information is
> >> prohibited. Please reply to the message immediately by informing the
> sender
> >> that the message was misdirected. After replying, please erase it from
> your
> >> computer system. Your assistance in correcting this error is
> appreciated.
> >>
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: DB2 v12 and IAG2

2020-12-22 Thread Attila Fogarasi

   1. IBM support site specifies:  IAG2 should remain disabled until
   further notice. Such notice will be provided at a later date at
   https://ibm.biz/db2znews.
   

   2. No such notice has appeared there yet, so the red alert is still in
   effect.   Pretty serious data loss impact in some scenarios.


On Mon, Dec 21, 2020 at 10:31 PM R.S. 
wrote:

> DB2 v12 introduced new Insert Algorithm 2 (IAG2), which was the topic of
> Red Alert and the recommendation was to disable it.
> Question: is it fixed somehow or the recommendation is still valid?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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: Build and submit proc

2020-12-22 Thread Tom Brennan

Whew!  Then I'm lucky I never really wrote any JCL - I always copy 
something similar.  In fact, if JCL had DNA I bet most could be traced 
back to a single IEBGENER job, formed in a tide pool eons ago.


On 12/22/2020 11:14 AM, Hobart Spitz wrote:

You can do it in batch REXX.

Stop being brain-dead and thinking about everything in terms of JCL.

I've don't write JCL anymore.

JCL causes brain-damage.


On Tuesday, December 22, 2020, Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:


I would build the JCL, and then FTP it with the filetype below.   That
will submit and run the job.

SITE FILEtype=JES NOJESGETBYDSN
put your.modified.jcl.


_
Dave Jousma
AVP | Director, Technology Engineering

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
Rapids, MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf
Of Fred Kaptein
Sent: Tuesday, December 22, 2020 12:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Build and submit proc

**CAUTION EXTERNAL EMAIL**

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

Hello,
I would like to build a JCL batch job called BACKUPS, that does the
following:
1) STEP01
 Create a JCL proc in MYLIB.PROCLIB(BKUP)
2) STEP02
 Execute the proc MYLIB.PROCLIB(BKUP)

My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was
built prior to submitting job BACKUPS.

Is there a way to do these two steps in one job and not two?

Thanks

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

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

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


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






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

Re: Build and submit proc

2020-12-22 Thread Paul Gilmartin

On Tue, 22 Dec 2020 13:14:07 -0600, Hobart Spitz wrote:

>You can do it in batch REXX.
>
>Stop being brain-dead and thinking about everything in terms of JCL.
>
>I've don't write JCL anymore.
>
>JCL causes brain-damage.
>
Be nice, or at least stay on-topic and ad-rem, not ad-hominem.

JCL and the Initiator provide protection against ENQ deadlock
not available with Rexx.


>On Tuesday, December 22, 2020, Jousma, David wrote:
>
>> I would build the JCL, and then FTP it with the filetype below.   That
>> will submit and run the job.
>>
Why is this preferable to just writing directly, or via IEBGENER to INTRDR?

>> SITE FILEtype=JES NOJESGETBYDSN
>> put your.modified.jcl.

-- gil

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

Re: Build and submit proc

2020-12-22 Thread Roger W Suhr

No need to be naughty here.

Roger W. Suhr

suhr...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Hobart Spitz
Sent: Tuesday, December 22, 2020 2:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Build and submit proc

You can do it in batch REXX.

Stop being brain-dead and thinking about everything in terms of JCL.

I've don't write JCL anymore.

JCL causes brain-damage.


On Tuesday, December 22, 2020, Jousma, David < 
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> I would build the JCL, and then FTP it with the filetype below.   That
> will submit and run the job.
>
> SITE FILEtype=JES NOJESGETBYDSN
> put your.modified.jcl.
>
> 
> _
> Dave Jousma
> AVP | Director, Technology Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Fred Kaptein
> Sent: Tuesday, December 22, 2020 12:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Build and submit proc
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> Hello,
> I would like to build a JCL batch job called BACKUPS, that does the
> following:
> 1) STEP01
> Create a JCL proc in MYLIB.PROCLIB(BKUP)
> 2) STEP02
> Execute the proc MYLIB.PROCLIB(BKUP)
>
> My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that 
> was built prior to submitting job BACKUPS.
>
> Is there a way to do these two steps in one job and not two?
>
> Thanks
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or 
> disseminate it in any manner. If you are not the intended recipient, 
> any disclosure, copying, distribution or use of the contents of this 
> information is prohibited. Please reply to the message immediately by 
> informing the sender that the message was misdirected. After replying, 
> please erase it from your computer system. Your assistance in correcting this 
> error is appreciated.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode or 
locate mode?
IBM has been looking for an HLL for program products; REXX is that language.

--
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: Build and submit proc

2020-12-22 Thread Hobart Spitz

You can do it in batch REXX.

Stop being brain-dead and thinking about everything in terms of JCL.

I've don't write JCL anymore.

JCL causes brain-damage.


On Tuesday, December 22, 2020, Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> I would build the JCL, and then FTP it with the filetype below.   That
> will submit and run the job.
>
> SITE FILEtype=JES NOJESGETBYDSN
> put your.modified.jcl.
>
> 
> _
> Dave Jousma
> AVP | Director, Technology Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Fred Kaptein
> Sent: Tuesday, December 22, 2020 12:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Build and submit proc
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> Hello,
> I would like to build a JCL batch job called BACKUPS, that does the
> following:
> 1) STEP01
> Create a JCL proc in MYLIB.PROCLIB(BKUP)
> 2) STEP02
> Execute the proc MYLIB.PROCLIB(BKUP)
>
> My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was
> built prior to submitting job BACKUPS.
>
> Is there a way to do these two steps in one job and not two?
>
> Thanks
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
> EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data in move mode
or locate mode?
IBM has been looking for an HLL for program products; REXX is that language.

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

Re: Build and submit proc

2020-12-22 Thread Jousma, David

I would build the JCL, and then FTP it with the filetype below.   That will 
submit and run the job.

SITE FILEtype=JES NOJESGETBYDSN
put your.modified.jcl.   

_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Fred Kaptein
Sent: Tuesday, December 22, 2020 12:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Build and submit proc

**CAUTION EXTERNAL EMAIL**

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

Hello,
I would like to build a JCL batch job called BACKUPS, that does the following:
1) STEP01
Create a JCL proc in MYLIB.PROCLIB(BKUP)
2) STEP02 
Execute the proc MYLIB.PROCLIB(BKUP)

My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was 
built prior to submitting job BACKUPS.

Is there a way to do these two steps in one job and not two?

Thanks 

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

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

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


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

Re: Build and submit proc

2020-12-22 Thread Paul Gilmartin

On Tue, 22 Dec 2020 12:23:49 -0500, David Spiegel wrote:
>
>The interpretation of JCL occurs before the execution starts. Hence,
>your result.
>If you were to SUBMIT your JCL to the internal reader in STEP02 (rather
>than trying to execute the BKUP Cataloged Procedure), the new job  would
>read the updated BKUP PROC.
> 
There might be a requirement for the submitted job to have a JOB
statement similar to the submitting job's.  The submitting job could
fetch its JOB statement with SDSF.

Referbacks are a harder problem.

Or, Rexx is your friend.  Use IRXJCL inline for the second step.


>On 2020-12-22 12:11, Fred Kaptein wrote:
>> Hello,
>> I would like to build a JCL batch job called BACKUPS, that does the 
>> following:
>> 1) STEP01
>>  Create a JCL proc in MYLIB.PROCLIB(BKUP)
>> 2) STEP02
>>  Execute the proc MYLIB.PROCLIB(BKUP)

-- gil

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

Re: Build and submit proc

2020-12-22 Thread Michael Brennan

No you can not do it with one batch job.  What you could do is have STEP1 
create the proc and then have STEP2 submit a separate batch job to the internal 
reader that executes the proc created in STEP1.

From: IBM Mainframe Discussion List  on behalf of 
Fred Kaptein 
Sent: Tuesday, December 22, 2020 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Build and submit proc

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello,
I would like to build a JCL batch job called BACKUPS, that does the following:
1) STEP01
Create a JCL proc in MYLIB.PROCLIB(BKUP)
2) STEP02
Execute the proc MYLIB.PROCLIB(BKUP)

My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was 
built prior to submitting job BACKUPS.

Is there a way to do these two steps in one job and not two?

Thanks

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

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

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

Re: Build and submit proc

2020-12-22 Thread Fred Kaptein

Thanks

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

Re: DEF(__STRING_CODESET__)?

2020-12-22 Thread Paul Gilmartin

(cross-posting)
On 2020-12-22, at 09:31:06, Kirk Wolf wrote:
> 
> This is the way that we do it -
> 
> #pragma convert("ISO8859-1")
> const char*  ASCII_LITERAL = "a literal string in ISO8859-1";
> #pragma convert(pop)
>  
I'm more interested in the wildly popular UTF-8.  On my
desktop I can:
791 $ locale
LC_CTYPE="en_US.UTF-8"
... 
792 $ echo aπb | sed 's/../x/'
xb

The regex substitution converts the first two characters,
the 'a' and the 'π' to the 'x'.

Suppose I'm Editing a similar file with ISPF Edit, CTYPE UTF-8,
which ISPF supports, and a CP875 terminal (which ISPF supports
but I don't have).  How does the analogous Edit command do
its magic:
Change r'..' 'x'

-- gil

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

Re: Build and submit proc

2020-12-22 Thread David Spiegel


Hi Fred,
The interpretation of JCL occurs before the execution starts. Hence, 
your result.
If you were to SUBMIT your JCL to the internal reader in STEP02 (rather 
than trying to execute the BKUP Cataloged Procedure), the new job  would 
read the updated BKUP PROC.


Regards,
David

On 2020-12-22 12:11, Fred Kaptein wrote:

Hello,
I would like to build a JCL batch job called BACKUPS, that does the following:
1) STEP01
 Create a JCL proc in MYLIB.PROCLIB(BKUP)
2) STEP02
 Execute the proc MYLIB.PROCLIB(BKUP)

My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was 
built prior to submitting job BACKUPS.

Is there a way to do these two steps in one job and not two?

Thanks

--
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: Build and submit proc

2020-12-22 Thread Itschak Mugzach

No. The interpreter already read the jcl at translation time.

בתאריך יום ג׳, 22 בדצמ׳ 2020, 19:11, מאת Fred Kaptein ‏<
fred.kapt...@telus.com>:

> Hello,
> I would like to build a JCL batch job called BACKUPS, that does the
> following:
> 1) STEP01
> Create a JCL proc in MYLIB.PROCLIB(BKUP)
> 2) STEP02
> Execute the proc MYLIB.PROCLIB(BKUP)
>
> My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was
> built prior to submitting job BACKUPS.
>
> Is there a way to do these two steps in one job and not two?
>
> Thanks
>
> --
> 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

Build and submit proc

2020-12-22 Thread Fred Kaptein

Hello,
I would like to build a JCL batch job called BACKUPS, that does the following:
1) STEP01
Create a JCL proc in MYLIB.PROCLIB(BKUP)
2) STEP02 
Execute the proc MYLIB.PROCLIB(BKUP)

My testing finds that STEP02 runs the proc in MYLIB.PROCLIB(BKUP) that was 
built prior to submitting job BACKUPS.

Is there a way to do these two steps in one job and not two?

Thanks 

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

Re: RFE: Some SuperC options should cater for longer lines

2020-12-22 Thread Seymour J Metz

Yes, the 32760 limit does not apply to EXCP.

Any DASD supporting BSAM can have spanned records. Track overflow is History.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, December 22, 2020 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RFE: Some SuperC options should cater for longer lines

On Tue, 22 Dec 2020 13:37:58 +, Seymour J Metz  wrote:

>> 27998, the non-spanned maximum blocksize for 3390 devices,
>
>That's the optimal block size, not the maximum.
>
For QSAM and BSAM, thee maximum block size is 32760.  It might
be larger for EXCP.

"non-spanned"?  Does 3390 have "spanned" blocks?  Track Overflow?

"optimal"?  I'd have said "optimum".

https://secure-web.cisco.com/1s945_GPWiDcPuD56IVL70HrpdQmeb5-LdAeiEOWJ7bDNgGYWpCoTLO_q2ESakOu_-u_weNrWt_-EP9XjnQWq67hvWO6xJmTF7ys1ciN73DosM4n1gy5wruR6zqRbTxkWS-iYL7BnuvlbpHWG_0tZufwSKJTvgBy8MwsMsreEpDFYchWVI6BZXLALk5a-tbhgAtyodQV7sTk-XnhflVHJ4NEAOZ4VC34eyrzX0NmTYcCoO3blX-stxFW4y3z2jOucY1C0mditoHIqlHu3dJyE3_d7oV_VVLrmCnWVb17px6TCOgB1XCKxPtl3y1BVj3HrYa_tUCRvGltoFPYEisLpvHlmhF0tI2mU50riP811v4v5zx6hDxflLhgjH2-j3vh6HYbcyAJWHzbH9GpC6CRuAfZqxI-qMtol7dcz3iTf4xfBxTzTl6oV61D5rkwDqn2m2-nbABDCB5FdsHTU_WJsfg/https%3A%2F%2Fenglish.stackexchange.com%2Fquestions%2F50843%2Fwhat-is-the-difference-between-optimal-and-optimum

>
>From:  Robert Prins
>Sent: Tuesday, December 22, 2020 6:47 AM
>
>On 2020-12-21 18:00, Paul Gilmartin wrote:
>> On Mon, 21 Dec 2020 19:38:30 +, Robert Prins  wrote:
>>
>>> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
>>>
>Updated to:
>
>It would be useful is the current limit would be raised to a higher value, and
>tentative maximum values could be 27998, the non-spanned maximum blocksize for
>3390 devices, or 32767, the maximum signed value for a halfword, but even a
>value of 1024 or 4096 would be more helpful.
>
One might argue for LINE_MAX, 2048:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxbd00/limitsh.htm

-- 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: DEF(__STRING_CODESET__)?

2020-12-22 Thread Kirk Wolf

This is the way that we do it -

#pragma convert("ISO8859-1")
const char*  ASCII_LITERAL = "a literal string in ISO8859-1";
#pragma convert(pop)

On Mon, Dec 21, 2020 at 5:05 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> In any z/OS 2.4 doc I can search, I find only a single reference
> to __STRING_CODESET__, in XL C/C++ User’s Guide:
>
> When NOASCII is in effect, the compiler uses the IBM-1047 code page
> for character constants and string literals, unless the code page is
> affected by other related options; for example, the CONVLIT, LOCALE,
> or DEF(__STRING_CODESET__) compiler options.
>
> Where is __STRING_CODESET__ defined, not just mentioned in passing?
> Can it be set to 1208?
>
> -- 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: DEF(__STRING_CODESET__)?

2020-12-22 Thread Paul Gilmartin

On Tue, 22 Dec 2020 12:13:46 +0100, Mario Bezzi wrote:

>Turns out that it's a typo in the documentation. The actual environment
>variable name is __STRING_CODE_SET__ and its use is described in the
>same manual.
>
>I hope this helps,
>
Thanks.  Have you submitted an RCF?

How do __STRING_CODE_SET__ and CONVLIT affect functions with
string arguments such as printf() and, especially, regcomp()?
I note that the ISPF Edit manual says that regular expressions in
Find and Change accommodate the code page of the attached
terminal, or 1047 in batch.

>On 12/22/20 12:05 AM, Paul Gilmartin wrote:
>> In any z/OS 2.4 doc I can search, I find only a single reference
>> to __STRING_CODESET__, in XL C/C++ User’s Guide:

-- gil

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

Re: RFE: Some SuperC options should cater for longer lines

2020-12-22 Thread Joe Monk

""non-spanned"?  Does 3390 have "spanned" blocks?  Track Overflow?

Yes it does.

"Variable-length records can be spanned (RECFM=DS or VS). Spanned records
can span more than one block."

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/da.htm

Joe

On Tue, Dec 22, 2020 at 8:37 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Dec 2020 13:37:58 +, Seymour J Metz  wrote:
>
> >> 27998, the non-spanned maximum blocksize for 3390 devices,
> >
> >That's the optimal block size, not the maximum.
> >
> For QSAM and BSAM, thee maximum block size is 32760.  It might
> be larger for EXCP.
>
> "non-spanned"?  Does 3390 have "spanned" blocks?  Track Overflow?
>
> "optimal"?  I'd have said "optimum".
>
> https://english.stackexchange.com/questions/50843/what-is-the-difference-between-optimal-and-optimum
>
> >
> >From:  Robert Prins
> >Sent: Tuesday, December 22, 2020 6:47 AM
> >
> >On 2020-12-21 18:00, Paul Gilmartin wrote:
> >> On Mon, 21 Dec 2020 19:38:30 +, Robert Prins  wrote:
> >>
> >>>
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
> >>>
> >Updated to:
> >
> >It would be useful is the current limit would be raised to a higher
> value, and
> >tentative maximum values could be 27998, the non-spanned maximum
> blocksize for
> >3390 devices, or 32767, the maximum signed value for a halfword, but even
> a
> >value of 1024 or 4096 would be more helpful.
> >
> One might argue for LINE_MAX, 2048:
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxbd00/limitsh.htm
>
> -- 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: RMODE64

2020-12-22 Thread Paul Gilmartin

On Tue, 22 Dec 2020 09:09:06 -0500, Joseph Reichman wrote:
>
>Thanks I’m not writing RMODE64 code don’t see a reason to 
>
>I don’t know why Ed co. does cann’t believe the code is that large 
>Thanks for the heads up about LE 
>
>I believe the real reason for RMODE64 is Java 
> 
And, perhaps, data CSECTs.


>> On Dec 22, 2020, at 8:57 AM, Peter Relson wrote:
>> 
>> VERY FEW system services officially support invocation in RMODE 64. If 
>> they don't say that they do, then do not assume that they do.
>>  ...
Is there a blanket statement to this effect in the relevant manual(s)?
 
-- gil

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

Re: RFE: Some SuperC options should cater for longer lines

2020-12-22 Thread Paul Gilmartin

On Tue, 22 Dec 2020 13:37:58 +, Seymour J Metz  wrote:

>> 27998, the non-spanned maximum blocksize for 3390 devices,
>
>That's the optimal block size, not the maximum.
>
For QSAM and BSAM, thee maximum block size is 32760.  It might
be larger for EXCP.

"non-spanned"?  Does 3390 have "spanned" blocks?  Track Overflow?

"optimal"?  I'd have said "optimum".

https://english.stackexchange.com/questions/50843/what-is-the-difference-between-optimal-and-optimum

>
>From:  Robert Prins
>Sent: Tuesday, December 22, 2020 6:47 AM
>
>On 2020-12-21 18:00, Paul Gilmartin wrote:
>> On Mon, 21 Dec 2020 19:38:30 +, Robert Prins  wrote:
>>
>>> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
>>>
>Updated to:
>
>It would be useful is the current limit would be raised to a higher value, and
>tentative maximum values could be 27998, the non-spanned maximum blocksize for
>3390 devices, or 32767, the maximum signed value for a halfword, but even a
>value of 1024 or 4096 would be more helpful.
>
One might argue for LINE_MAX, 2048:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxbd00/limitsh.htm

-- gil

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

Re: RMODE64

2020-12-22 Thread Joseph Reichman

Peter 

Thanks I’m not writing RMODE64 code don’t see a reason to 

I don’t know why Ed co. does cann’t believe the code is that large 
Thanks for the heads up about LE 

I believe the real reason for RMODE64 is Java 



> On Dec 22, 2020, at 8:57 AM, Peter Relson  wrote:
> 
> Since z/OS 2.3 you have been able to identify modules as wanting to be 
> RMODE 64, via what Ed Jaffe mentioned (including RMODEX=64TRUE).
> Just about the only thing that is guaranteed for an RMODE 64 module is 
> that your module will survive being undispatched and redispatched (such as 
> on a time slice).
> 
> VERY FEW system services officially support invocation in RMODE 64. If 
> they don't say that they do, then do not assume that they do. In practice 
> services that are SVC-entered or PC-entered might well work enough for 
> your purposes (and I intentionally used the word "enough" because there 
> might be things that you do not notice that are not fully supported, 
> particularly with respect to diagnostic data). Things that are 
> branch-entered might "get there" but might well not "get back". Be careful 
> about referencing parameters that are within your module for a service 
> that does not document that it accepts parameter data above 2G. Any 
> service that has a "SAM31" (or SAM24) as part of its expansion will of 
> course not work in RMODE 64. Many things cannot be RMODE 64. including 
> IRBs, SRBs, recovery routines, retry points. All of these relate to there 
> being only a 4-byte area to capture the initial address. Obviously after 
> getting control you can branch elsewhere. For recovery routine retry, one 
> way to accomplish retrying to an area in an RMODE 64 module is to set up 
> 64-bit retry register 15 with the pointer-defined address of where you 
> "really want to go" and retry to CVTBSM0F. You might also need SETRP 
> RETRY15=YES so that your retry register 15 is honored.
> 
> If your RMODE 64 module calls no services (and of course is AMODE 64) it 
> will work if correctly written. 
> 
> There has been no proven need for RMODE 64 for modules (despite the 
> abominable code bloat of some application approaches).  Applications have 
> been moving their data above 2G for many years. 
> 
> The eventual intent is for LE to support your RMODE 64 modules via the LE 
> services that you can call. The LE services will pay attention to whether 
> the underlying system service supports RMODE 64 or not. I've lost track of 
> whether this is available or not, and, if not available, when it might be.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> 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: RMODE64

2020-12-22 Thread Peter Relson

Since z/OS 2.3 you have been able to identify modules as wanting to be 
RMODE 64, via what Ed Jaffe mentioned (including RMODEX=64TRUE).
Just about the only thing that is guaranteed for an RMODE 64 module is 
that your module will survive being undispatched and redispatched (such as 
on a time slice).

VERY FEW system services officially support invocation in RMODE 64. If 
they don't say that they do, then do not assume that they do. In practice 
services that are SVC-entered or PC-entered might well work enough for 
your purposes (and I intentionally used the word "enough" because there 
might be things that you do not notice that are not fully supported, 
particularly with respect to diagnostic data). Things that are 
branch-entered might "get there" but might well not "get back". Be careful 
about referencing parameters that are within your module for a service 
that does not document that it accepts parameter data above 2G. Any 
service that has a "SAM31" (or SAM24) as part of its expansion will of 
course not work in RMODE 64. Many things cannot be RMODE 64. including 
IRBs, SRBs, recovery routines, retry points. All of these relate to there 
being only a 4-byte area to capture the initial address. Obviously after 
getting control you can branch elsewhere. For recovery routine retry, one 
way to accomplish retrying to an area in an RMODE 64 module is to set up 
64-bit retry register 15 with the pointer-defined address of where you 
"really want to go" and retry to CVTBSM0F. You might also need SETRP 
RETRY15=YES so that your retry register 15 is honored.

If your RMODE 64 module calls no services (and of course is AMODE 64) it 
will work if correctly written. 

There has been no proven need for RMODE 64 for modules (despite the 
abominable code bloat of some application approaches).  Applications have 
been moving their data above 2G for many years. 

The eventual intent is for LE to support your RMODE 64 modules via the LE 
services that you can call. The LE services will pay attention to whether 
the underlying system service supports RMODE 64 or not. I've lost track of 
whether this is available or not, and, if not available, when it might be.

Peter Relson
z/OS Core Technology Design


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

Re: RFE: Some SuperC options should cater for longer lines

2020-12-22 Thread Seymour J Metz

> 27998, the non-spanned maximum blocksize for 3390 devices,

That's the optimal block size, not the maximum.




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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [robert.ah.pr...@gmail.com]
Sent: Tuesday, December 22, 2020 6:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RFE: Some SuperC options should cater for longer lines

On 2020-12-21 18:00, Paul Gilmartin wrote:
> On Mon, 21 Dec 2020 19:38:30 +, Robert Prins  wrote:
>
>> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
>>
> Where I read:
>  It would be useful is the current limit would be raised to a higher 
> value,
>  and the logical value would be 32767, the maximum 2-byte signed value.
>
> Ummm...
>  32760 for RECFM=FB
>  32756 for RECFM=VB
>   for RECFM=VBS  (but does SuperC support VBS?)
>   for UNIX files
> But I believe for UNIX, SUPERC uses QSAM, which imposes the limits above.
>
> Underreaching.  SuperC should impose *no* limit of its own, but simply
> OPEN OLDDD and NEWDD and reflect any errors reported by OPEN.
> Access method limitations are documented in "Using Data Sets".
>
> (When last I tried, SuperC accepted allocated UNIX files for OLDD
>   and NEWDD, but not for DELDD.  Go figger.)

Updated to:

It would be useful is the current limit would be raised to a higher value, and
tentative maximum values could be 27998, the non-spanned maximum blocksize for
3390 devices, or 32767, the maximum signed value for a halfword, but even a
value of 1024 or 4096 would be more helpful.

--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - 
https://secure-web.cisco.com/1fY3ETqcBDtdts-bgTZ0S5I_14qCzzpAZKfw3_Gba59WiK7MGnssYQeMul8XMxP8D4dcu7aFntnq5B5CUj7g7Vj8aUdKGUMlVaE14Z1rAmvS8ONbiPNPF6UYobmu2RQZWtYF67blTRVef9heKeb0xGcLEN2FP2OxzKM1X0hThQiw5xrD0oPIw4jmFg90In-RajqU3ENBFXKBgriYBMWjyLnRgBy6IHZPT_TV_R5EJoVQ5bFA8ddk1y5yYE6EJp4f4tRKsU2WrIWRQMrJNXQW6YwI61Wx1PYehGsC2Vljzoz6N5AFT-TbSOwlSK4nK8L5jN1G2qBZ342_U2Y0EbUWplk4EgKa8N2Rwede5Ibvjov8FeiaEIvZ8r4HRyYRPMCDlTYEpedxUsImiL1vMk_YdZGQJC0Ufm4DZbyfUjtX3h9HQPsHU5kIs_nBKX86ASXu5/https%3A%2F%2Fprino.neocities.org%2F
Some REXX code for use on z/OS - 
https://secure-web.cisco.com/1NkflYZPw5LPHXVnfhyLDydnTvPNfnGd8Rwy3AA-n1MLZi6UzIQnU1aQjpZyMmYPwux1QSpugP657-ul-xYfsho3g3r6OyTbShjD-vPhgYgpXyvfBfHFqEQoTQbIj_bytA3evLjclDXzL7XOyf9VwH4MeACGMIZMfS_pgMgAzUqGvhlW-iOGi9Hu7UmPte33g2MAhA2DPI2tCMiLtQDlHfPkUhaenS_txOjLX3U0pwtIpo_qtu4ASIe-XNHTir5-E4Mk5dtpOBZOoJDWTNkN8AREeHBrsMZKLQdy89Kl_rekVCM2wJ-2AKNnFkWKgvj6vZqlDN0-mruJSkM-0sGYOJMZBWKY6ABca5kpBPOj1liCWE4GkS6mYtlLObfRmRCZdMC8FLTiC66N3iFQaHNMSgsDpDeJRcMGW2QskT-Sw-dLBg9yqSH3iaKkGCTedq23t/https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.html

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

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

Re: DEF(__STRING_CODESET__)?

2020-12-22 Thread Mario Bezzi

Turns out that it's a typo in the documentation. The actual environment 
variable name is __STRING_CODE_SET__ and its use is described in the 
same manual.


I hope this helps,
mario

On 12/22/20 12:05 AM, Paul Gilmartin wrote:

In any z/OS 2.4 doc I can search, I find only a single reference
to __STRING_CODESET__, in XL C/C++ User’s Guide:

 When NOASCII is in effect, the compiler uses the IBM-1047 code page
 for character constants and string literals, unless the code page is
 affected by other related options; for example, the CONVLIT, LOCALE,
 or DEF(__STRING_CODESET__) compiler options.

Where is __STRING_CODESET__ defined, not just mentioned in passing?
Can it be set to 1208?

-- 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: RFE: Some SuperC options should cater for longer lines

2020-12-22 Thread Robert Prins


On 2020-12-21 18:00, Paul Gilmartin wrote:

On Mon, 21 Dec 2020 19:38:30 +, Robert Prins  wrote:


https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550


Where I read:
 It would be useful is the current limit would be raised to a higher value,
 and the logical value would be 32767, the maximum 2-byte signed value.

Ummm...
 32760 for RECFM=FB
 32756 for RECFM=VB
  for RECFM=VBS  (but does SuperC support VBS?)
  for UNIX files
But I believe for UNIX, SUPERC uses QSAM, which imposes the limits above.

Underreaching.  SuperC should impose *no* limit of its own, but simply
OPEN OLDDD and NEWDD and reflect any errors reported by OPEN.
Access method limitations are documented in "Using Data Sets".

(When last I tried, SuperC accepted allocated UNIX files for OLDD
  and NEWDD, but not for DELDD.  Go figger.)


Updated to:

It would be useful is the current limit would be raised to a higher value, and 
tentative maximum values could be 27998, the non-spanned maximum blocksize for 
3390 devices, or 32767, the maximum signed value for a halfword, but even a 
value of 1024 or 4096 would be more helpful.


--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

48 matches

Mail list logo