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&CR_ID=147550 Where I read: It would be useful is the current limit would be raised to a higher value, and the logical v

Re: DEF(__STRING_CODESET__)?

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 __

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

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

Re: RMODE64

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 slic

Re: RMODE64

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 h

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"

Re: RMODE64

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

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

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

Re: DEF(__STRING_CODESET__)?

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_

Re: DEF(__STRING_CODESET__)?

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

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

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 o

Build and submit proc

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

Re: Build and submit proc

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

Re: Build and submit proc

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

Re: DEF(__STRING_CODESET__)?

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

Re: Build and submit proc

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

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 Fr

Re: Build and submit proc

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

Re: Build and submit proc

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

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

Re: Build and submit proc

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 bein

Re: Build and submit proc

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 I

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

Re: DB2 v12 and IAG2

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,

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

Re: Build and submit proc

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

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 JC

Re: Build and submit proc

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 programm

Re: Build and submit proc

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

Re: Build and submit proc

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 bo

Re: Build and submit proc

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

Re: Build and submit proc

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]

Re: Build and submit proc

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.

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 wan

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

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

Re: JCL divergence

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

Re: Build and submit proc

> 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

Re: JCL divergence

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 thin

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

Re: Build and submit proc

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

Re: JCL divergence

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

Re: JCL divergence

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

Re: JCL divergence

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

Re: JCL divergence

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

Re: Build and submit proc

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 call

Installing RHEL 8.3 in Native LPAR

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 ou

Re: Build and submit proc

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 unde