Re: Interesting article on UNICODE.

[Default] On 8 May 2017 07:07:29 -0700, in bit.listserv.ibm-main john.archie.mck...@gmail.com (John McKown) wrote: >This may be old hat to many/most here. But I found it quite interesting. >And perhaps more important now that IBM is emphasizing z/OS in the "mobile" >world. >

Re: JCL null statement

Yes, 'refer' for my eyes only. But no, I don't cancel after submit. I save the member with old lines copied safely to the bottom out of harm's way. JESx does not see them. They're there for my personal future reference and perhaps reuse. . . J.O.Skip Robinson Southern California Edison Company

Re: JCL null statement

On 2017-05-09, at 16:57, Jesse 1 Robinson wrote: > I've used null cards for decades to terminate the JES-readable lines is a job > stream. Rather than maintain a dozen similar job members that vary only > slightly from one run to another, I copy key but variable lines after a null > card at

Re: S0D5 accessing dataspace

On 2017-05-09 17:23, Gary Weinhold wrote: Since no one suggested it, I guess it is not likely that the site would have a monitor or exit that would change a non-swappable address space to swappable. We twice experienced ABEND0D5-21 at one customer site, in 1992 and 1993. In both cases, the

Re: JCL null statement

On Tue, 9 May 2017 23:16:09 +0100, David W Noon wrote: > >Only using INTRDR. Other SYSOUT streams have to tolerate any character >sequence and cannot safely reserve them for commands to the writer >(unless some custom writer can process commands). The other IBM writers >do not have internal

Re: JCL null statement

I've used null cards for decades to terminate the JES-readable lines is a job stream. Rather than maintain a dozen similar job members that vary only slightly from one run to another, I copy key but variable lines after a null card at the bottom. I can refer to those lines or even copy them

Re: S0D5 accessing dataspace

It is better for performance to do the TRANSWAP before acquiring a lot of storage, since that will reduce the number of fixed frames than need to be moved to non-reconfigurable storage by the TRANSWAP. However, the order of the TRANSWAP relative to the DSPSERV CREATE should have no effect on

Re: JCL null statement

On Tue, 9 May 2017 16:33:35 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: JCL null statement (Was: job output into dataset" (in <2883779052307729.wa.paulgboulderaim@listserv.ua.edu>): [snip] What happens to any additional records between the null

Re: JCL null statement (Was: job output into dataset

On Tue, 9 May 2017 21:39:52 +0100, David W Noon wrote: >On Tue, 9 May 2017 14:56:33 -0500, Paul Gilmartin >(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: job >output into dataset" (in ><5975685166305075.wa.paulgboulderaim@listserv.ua.edu>): > >> On Tue, 9 May 2017 20:20:10

Re: S0D5 accessing dataspace

Thanks to those who responded; here's an update on this abend: Although it's possible, I doubt we have a bug in our logic in this area; this has run for more than 10 years at multiple sites on multiple levels of z/OS. And we do not ever issue a TRANSWAP OKSWAP; the dataspace is designed to

JCL null statement (Was: job output into dataset

On Tue, 9 May 2017 14:56:33 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: job output into dataset" (in <5975685166305075.wa.paulgboulderaim@listserv.ua.edu>): On Tue, 9 May 2017 20:20:10 +0100, David W Noon wrote: [snip] What kind of null

Re: job output into dataset

On Tue, 9 May 2017 13:38:02 -0500, Tom Marchant wrote: > >The behavior that David describes is very old. Back in the 70's, >operators would routinely add a null JCL statement to the end of >a tray of JCL to be processed so that the last job would be >processed immediately. I just submitted such

Re: job output into dataset

On Tue, 9 May 2017 20:20:10 +0100, David W Noon wrote: >On Tue, 9 May 2017 13:25:43 -0500, Paul Gilmartin >(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: job >output into dataset" (in ><679800532864.wa.paulgboulderaim@listserv.ua.edu>): > >> On Tue, 9 May 2017 18:59:23

Re: job output into dataset

On Tue, 9 May 2017 13:25:43 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: job output into dataset" (in <679800532864.wa.paulgboulderaim@listserv.ua.edu>): On Tue, 9 May 2017 18:59:23 +0100, David W Noon wrote: The INTRDR writer will "spin"

Re: job output into dataset

It also returns the JES JobId of the submitted job which is extremely helpful if the same JobName is submitted multiple times. Sent from my iPhone > On May 9, 2017, at 14:58, John McKown wrote: > > Also, any more, I use the ACB interface instead of the DCB

Re: job output into dataset

On Tue, May 9, 2017 at 1:25 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 9 May 2017 18:59:23 +0100, David W Noon wrote: > > > >The INTRDR writer will "spin" a job stream to the input spool > >automatically when: > > > > i) the job stream arrives at a

Re: job output into dataset

On Tue, 9 May 2017 13:25:43 -0500, Paul Gilmartin wrote: >On Tue, 9 May 2017 18:59:23 +0100, David W Noon wrote: >> i) the job stream arrives at a null statement; >>... >I'm skeptical about that point since I often submit jobs with noise >such as comments after a null statement and SDSF

Re: job output into dataset

On Tue, 9 May 2017 18:59:23 +0100, David W Noon wrote: > >The INTRDR writer will "spin" a job stream to the input spool >automatically when: > > i) the job stream arrives at a null statement; >... I'm skeptical about that point since I often submit jobs with noise such as comments after a

Re: job output into dataset

On Tue, 9 May 2017 18:59:23 +0100, David W Noon wrote: > >The INTRDR writer will "spin" a job stream to the input spool >automatically when: > > i) the job stream arrives at a null statement; > > ii) the job stream arrives at a new JOB statement; > >iii) the SYSOUT DD statement is closed. >

JCL or ...? (was: job output into dataset)

On 2017-05-09, at 10:20, Farley, Peter x23353 wrote: > Burroughs 5500 MCS (and possibly later, I didn't get to see those) had WFL, > Work Flow Language, which was nearly the full Burroughs Algol language, minus > the I/O facilities. > > Very powerful and flexible. Your "JCL" was an actual

Re: job output into dataset

On Tue, 9 May 2017 12:52:19 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: job output into dataset" (in <3155439687677594.wa.paulgboulderaim@listserv.ua.edu>): On Tue, 9 May 2017 10:16:00 -0700, Lizette Koehler wrote: You can SPIN SYSOUT (I do

Re: job output into dataset

On Tue, 9 May 2017 10:16:00 -0700, Lizette Koehler wrote: > >You can SPIN SYSOUT (I do not think you can SPIN INTRDR ) > For INTRDR, the program can close it (and re-open or FREE and re-ALLOCATE.) I don't think I'd want to spin INTRDR by an external command unless I knew that data set was at a

Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY

Since the JCL has a reference to the DSN after the DFDSS step, the enqueue that is causing your conflict is held by the initiator, not by DFDSS. The section I quoted has additional text that describes how DFDSS uses the initiator's enqueue. You need to look at that to determine how it affects

Re: AW: Re: job output into dataset

Venkat - You can SPIN SYSOUT (I do not think you can SPIN INTRDR ) Sometimes, the SYSOUT is not PURGED from the Job unless you have SPIN=CLOSE,FREE=UNALLOC. Otherwise the purge of the output will occur when the task is shut down. JES2 keeps a counter of output written. When it gets to a

AW: Re: Tons of IARV64 System Trace entries - Is this due to taking a copy of the System Trace tables?

> Yes, the IARV64 entries are system trace snapshot processing pagefixing the snapshot buffer. Thanks a lot for the confirmation. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send

Re: Tons of IARV64 System Trace entries - Is this due to taking a copy of the System Trace tables?

Yes, the IARV64 entries are system trace snapshot processing pagefixing the snapshot buffer. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > The only question I have for the moment is: Are those IARV64 entries > related to saving the system trace table

Re: BUILDMCS fallout

In my previous reply, I was going to mention UCL but removed that reference. UCL is a great hammer that hits what you aim it at but cannot tell you what else you should be pounding as well. That's why I prefer to (re)traverse the SMPE path RECEIVE and APPLY to get all the related pieces in

Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY

The job does reference the dsn after it is enabled on CICS. Since the dsn is OAM the SHARE parm does appy. Right? On Tue, 5/9/17, retired mainframer wrote: Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY To:

Re: JCL System symbols

-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Saturday, May 06, 2017 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: JCL System symbols > My earlier post did not consider dynamic system symbols. There

Re: AW: Re: job output into dataset

Burroughs 5500 MCS (and possibly later, I didn't get to see those) had WFL, Work Flow Language, which was nearly the full Burroughs Algol language, minus the I/O facilities. Very powerful and flexible. Your "JCL" was an actual program, and IIRC it was compiled for execution. Fun stuff.

Re: Interesting article on UNICODE.

What about it LOL? (I'm not a Java fan.) Someone else posted that Java sort of does this, only UTF-16. I have some experience with UTF-16 in Windows and as I said I think it is the worst of all possible worlds: it doubles storage requirements while lulling you into thinking that character

Re: Merging SYSPLEXes Information....

The problem of merging sysplexes is a superset of merging LPARs. You have to manage all the issues of LPAR merge as well as sysplex merge. For the most part, sysplex issues are easier at the CF and couple data set level. The really hard thing is resolving data set names all the way from TSO

Re: BUILDMCS fallout

Yea, I think you are correct Rob. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message-

Re: BUILDMCS fallout

There is a warning that the target and dist should be at the same level. Which makes me think that anyth Maybe just backing off the usermod, and then receive / apply after the buildmcs is complete. Rob Schramm On Tue, May 9, 2017, 10:49 AM Allan Staller wrote: >

Re: job output into dataset

On Tue, 9 May 2017 10:21:38 -0500, Tom Marchant wrote: > >How many languages had a PRAGMA directive when ASP was written in the 1960's? > I see that as having been an excellent opportunity to innovate. IBM often misses such opportunities. The term "pragma[t]" appears to have originated with

Re: BUILDMCS fallout

I scanned the SMPPUNCH of the BUILDMCS and found these: ++MOD(IGYCDOPT) DISTLIB(AIGYMOD1) FROMDS(DSN(IGY.AIGYMOD1) NUMBER(2) VOL(DLB01A) UNIT(3390)) RMID(MCOB001) LMOD(IGYCDOPT) . ++SRC(IGYCDOPT) DISTLIB(AIGYSRC1) FROMDS(DSN(IGY.AIGYSRC1) NUMBER(1) VOL(DLB01A)

Re: BUILDMCS fallout

Skip, Thanks for the response. I thought I had done everything right, including all the nuances of BUILDMCS. I had accepted all maintenance to the COBOL FMID's prior to the BUILDMCS. The usermod was NOT accepted. As for ongoing maint, we will probably be in a converting mode for a year or

Re: AW: Re: job output into dataset

On Tue, May 9, 2017 at 10:03 AM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 9 May 2017 09:54:22 -0500, Tom Marchant wrote: > > >On Tue, 9 May 2017 08:16:48 -0600, Paul Gilmartin wrote: > > > >>The JCL Ref. indicates that they are available to the >

Re: AW: Re: job output into dataset

On Tue, 9 May 2017 10:03:04 -0500, Paul Gilmartin wrote: >On Tue, 9 May 2017 09:54:22 -0500, Tom Marchant wrote: > >>There is a good reason it looks like a comment. >>It allows JCL to be coded that contains Job Entry Control Language statements >>for both JES2 and JES3, so that it can be run in

Re: BUILDMCS fallout

Leaving aside for the moment the question of whether it's really necessary to 'move' COBOL 4.2 to a separate environment, the SMPE anomalies cited are due mostly to how BUILDMCS works. That process is based on dlibs, not on targets, so any sysmod that is applied but not accepted will not be

Re: Merging SYSPLEXes Information....

Hello, Yes the SYSPLEXes are all physically in the same site. My feel is that it has to be easier/cheaper/less risk to migrate entire LPARs, rather than to migrate application by application. I will read through the red book suggested (also recommended by Kees and Allan. Thanks On Tue, May 9,

Re: AW: Re: job output into dataset

On Tue, 9 May 2017 09:54:22 -0500, Tom Marchant wrote: >On Tue, 9 May 2017 08:16:48 -0600, Paul Gilmartin wrote: > >>The JCL Ref. indicates that they are available to the >>//*FORMAT PR statement. >> >>("//*FORMAT PR" looks uncomfortably like a comment. Is >>this a reserved comment? Ugh!) >

Re: BUILDMCS fallout

My bad. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, May 9, 2017 9:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BUILDMCS fallout Sorry, DDDEF DDnames are the same between releases, and the apply of

Re: AW: Re: job output into dataset

On Tue, May 9, 2017 at 9:16 AM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On 2017-05-09, at 01:42, venkat kulkarni wrote: > > > Yes. It's not.so I should code jesmsglg dd stmt as > > //JESMSGLG dd sysout=a,free=close,spin=unalloc > > > > in my ims proc and then

Re: AW: Re: job output into dataset

On Tue, 9 May 2017 08:16:48 -0600, Paul Gilmartin wrote: >The JCL Ref. indicates that they are available to the >//*FORMAT PR statement. > >("//*FORMAT PR" looks uncomfortably like a comment. Is >this a reserved comment? Ugh!) It's a JES3 JECL statement. There is a good reason it looks like a

Re: BUILDMCS fallout

Sorry, DDDEF DDnames are the same between releases, and the apply of HADB610 contains ++DELETES for the old releases. HADB400 DELETED FUNCTION HADB420 DELETED FUNCTION

Re: BUILDMCS fallout

Different FMID's. IIRC, different DDDEFs. Should not be any conflict with both compilers in the same zone. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Tuesday, May 9, 2017 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU

BUILDMCS fallout

All, Maybe a SMPE guru can help me. We are starting to work on conversion project to move from Enterprise COBOL 4.2 to 6.1 and as part of the installation, I did a BUILDMCS on the FMID's for V4.2 so that I could move it into its own set of zones, so that I could install V6.1 into my z/OS

Re: AW: Re: job output into dataset

On Tue, 9 May 2017 16:01:33 +0300, venkat kulkarni wrote: >and also after spin, all these messages should be no longer exist in this >imsproc. SPIN does not delete messages. It makes them available for print or cancel. -- Tom Marchant

Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Tuesday, May 09, 2017 6:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFDSS QUESTION :SHARE PARM WHEN DOING COPY > > Good Day To All, > > Could someone

Re: AW: Re: job output into dataset

On 2017-05-09, at 01:42, venkat kulkarni wrote: > Yes. It's not.so I should code jesmsglg dd stmt as > //JESMSGLG dd sysout=a,free=close,spin=unalloc > > in my ims proc and then recycle ims and then issue > $t job,imsproc,spin,ddname=JESMSGLG > Command to spin JESMSGLG. > The JCL Ref. lists

Re: IBM Doc Buddy V1.3.0 supports online search

Installed on my Android phone. Very nice, thanks! Regards and thanks Paul -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jialei Ma Sent: Tuesday, May 09, 2017 4:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM Doc Buddy V1.3.0

Re: Merging SYSPLEXes Information....

Cameron Conacherwrote: >I am looking for any information to read that is related to Merging SYSPLEXes. >We have a few SYSPLEXes, each with a couple of LPARs. I wanted to see how much >effort would be involved in collapsing into fewer SYSPLEXes. It depends of course. Are these Sysplexes all at

Re: Merging SYSPLEXes Information....

For this purpose, consider the mergee SPSPLEX a single image. I imagine largest effort will be RACF. See the manual "Merging Systems into a SYSPLEX". Not sure if the is the most current version: http://www.redbooks.ibm.com/redbooks/pdfs/sg246818.pdf HTH, Good Morning everyone, I am looking

Re: Merging SYSPLEXes Information....

Although it is rather old, this may help: http://www.redbooks.ibm.com/redbooks/pdfs/sg246818.pdf "This document discusses the things to be considered when an existing system (or group of systems) is to be moved into an existing sysplex." Kees. > -Original Message- > From: IBM

Tons of IARV64 System Trace entries - Is this due to taking a copy of the System Trace tables?

I'm busy analysing yet another puzzling problem. There is a program that seems to be in a recovery loop, yet this does not yet make much sense. I've got an SVCDUMP and am having a look at the system trace. I see the following pattern to repeat: *PGM 00A*RCVY PROG*SVC D*RCVY ESTA*RCVY ESTR

Merging SYSPLEXes Information....

Good Morning everyone, I am looking for any information to read that is related to Merging SYSPLEXes. We have a few SYSPLEXes, each with a couple of LPARs. I wanted to see how much effort would be involved in collapsing into fewer SYSPLEXes. Once I collapse say SYSPLEX#7 into SYSPLEX #1, all of

DFDSS QUESTION :SHARE PARM WHEN DOING COPY

Good Day To All, Could someone clarify the explanation and my understanding about the SHARE parm when using COPY. Following is the explanation in the doc: SHARE specifies that DFSMSdss is to share the data sets to be copied for read access with other programs. SHARE and FULL are mutually

Re: AW: Re: job output into dataset

Hello Lizette, Sorry for consuming lots of time on this issue. But, I wanted to get clarity on very basic like, 1) If I see more records in one of the JES* DD statement Ex : JESMSGLG in my IMS address space and I want to spin this messages from this address space and put it in one dataset

Re: AW: Re: job output into dataset

Yes. It's not.so I should code jesmsglg dd stmt as //JESMSGLG dd sysout=a,free=close,spin=unalloc in my ims proc and then recycle ims and then issue $t job,imsproc,spin,ddname=JESMSGLG Command to spin JESMSGLG. Please correct me, if my understanding is wrong. Also, suggest after this spin , how

Re: AW: Re: job output into dataset

There is no DD named JCLOUT. There is nothing (aside from the JESx) to SPIN. Why do you want to spin job? > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of venkat kulkarni > Sent: Monday, May 08, 2017 10:44 PM > To: