Re: Interesting article on UNICODE.

[Clark Morris]

[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.
>
>http://reedbeta.com/blog/programmers-intro-to-unicode/
>
>IMO, something that IBM languages could find really useful is Google Go's
>concept of a "rune". A "rune" is what Go uses instead of the longer
>"UNICODE Code Point". It is basically the _concept_ of a "letter" without
>any specific bit encoding. E.g. U+0061 is "LOWER CASE LATIN LETTER A". But
>U+0061 is NOT 0x61 (UTF-8) or 0x0061 (UTF-16BE) or 0x6100 (UTF-16LE).
>Unfortunately the language COBOL only has a PIC X. Which is "one 8 bit
>byte". There's not even a _concept_ of a UNICODE Code Point in COBOL. And,
>honestly, I don't really see how to implement such in COBOL, unless they
>just do the "easy" thing and use UTF-32. Which really "wastes" bytes in
>memory and on disk. Uh, unless your DASD array does some sort of
>transparent compression on the back end.

See USAGE NATIONAL and PICTURE N in the more recent COBOL manuals.
USAGE NATIONAL is UTF-16.  There is also provision for DBCS.  This is
not VS COBOL release 1.4.  We are in a new world.  Now if they would
recognize USAGE BIT and all of the other usages in the 2002 standard
justifying it on needing to handle all of the data types in SQL (and
on the SMF records).  

Clark Morris

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

Re: JCL null statement

[Jesse 1 Robinson]

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
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 09, 2017 4:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 the bottom. I can refer to those lines or even copy them back to the 
> execution stream ...
>  
Me, too.  "View; make desired changes (dismiss annoying warning); SUBmit; 
CANcel.
"refer" seems irrelevant since JES(2) never reads them.  Oh! a mnemonic 
"refer", not a JCL "refer".

> to get desired results while maintaining only one PDS member. JES(2) never 
> reads or echoes past the null card.
>   

I thought I had observed otherwise (with memorable astonishment), but I can no 
longer exhibit an example.

-- gil


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

Re: JCL null statement

[Paul Gilmartin]

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 the bottom. I can refer to those lines or even copy them back to the 
> execution stream ...
>  
Me, too.  "View; make desired changes (dismiss annoying warning); SUBmit; 
CANcel.
"refer" seems irrelevant since JES(2) never reads them.  Oh! a mnemonic "refer",
not a JCL "refer".

> to get desired results while maintaining only one PDS member. JES(2) never 
> reads or echoes past the null card.
>   

I thought I had observed otherwise (with memorable astonishment),
but I can no longer exhibit an example.

-- gil

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

Re: S0D5 accessing dataspace

[Gord Tomlin]

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 alleged performance guru at the site used their 
monitoring product (can't remember whether it was Omegamon or TMON) to 
swap out a started task that needed to be non-swappable.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

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

Re: JCL null statement

[Paul Gilmartin]

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 commands, AFAIAA.
>
>> What happens if the operator issues "$TOJ W=INTRDR" on an ordinary
>> SYSOUT data set after the fact?
>
>Probably nothing good.
>
Or a SYSOUT class having W=INTRDR.

Or multiple OUTPUT statements applicable to a single DD SYSOUT with
some having W=INTRDR and others having no writer or a writer other
than INTRDR.

(The JCL Ref. cautions against having INTRDR on the DD statement but
a(nother) writer on the OUTPUT statement, but I don't see any prohibition
of different writers on various applicable OUTPUT statements.)

Generally, options on the DD statement override any on the OUTPUT
statement(s).  INTRDR seems to be an exception.

-- gil

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

Re: JCL null statement

[Jesse 1 Robinson]

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 back to the 
execution stream to get desired results while maintaining only one PDS member. 
JES(2) never reads or echoes past the null card. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David W Noon
Sent: Tuesday, May 09, 2017 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 statement and 
> the next JOB statement?  are they quietly ignored (with perhaps a 
> message to operator?)

The IBM term is "flushed". They never hit the spool and no console message is 
issued.

> At what point if any in the logic does the access method recognize 
> INTRDR as special, different from ordinary SYSOUT?

QSAM doesn't distinguish between INTRDR and any other SYSOUT writer. 
VSAM detects on the OPEN and uses a specific form called JAM (JES Access 
Method).

> Does the
> //
> /*EOF
> ... that John M. mentioned cause flushing of any SYSOUT or only one 
> with W=INTRDR?

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 
commands, AFAIAA.

> What happens if the operator issues "$TOJ W=INTRDR" on an ordinary 
> SYSOUT data set after the fact?

Probably nothing good.
--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


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

Re: S0D5 accessing dataspace

[Jim Mulder]

 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
the 0D5 abend, which would have occurred because the address space was
swappable (and logically swapped) at the time of the storage access which 
got
the abend. 


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

> 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 be accessible until the job 
> ends.  Rob Scott's suggestion that moving The SYSEVENT TRANSWAP 
> before the DSPSERV CREATE is worth trying especially if we can find 
> a way to reproduce the abend.
> 
> If the abend recurs at this site (or anywhere else), I will surely 
> get the output of a D J and an SVCDUMP.
> 
> 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.



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

Re: JCL null statement

[David W Noon]

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 statement and
the next JOB statement?  are they quietly ignored (with perhaps a message
to operator?)


The IBM term is "flushed". They never hit the spool and no console 
message is issued.



At what point if any in the logic does the access method recognize INTRDR
as special, different from ordinary SYSOUT?


QSAM doesn't distinguish between INTRDR and any other SYSOUT writer. 
VSAM detects on the OPEN and uses a specific form called JAM (JES Access 
Method).



Does the
//
/*EOF
... that John M. mentioned cause flushing of any SYSOUT or only one with
W=INTRDR?


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 commands, AFAIAA.



What happens if the operator issues "$TOJ W=INTRDR" on an ordinary
SYSOUT data set after the fact?


Probably nothing good.
--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

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

[Paul Gilmartin]

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 +0100, David W Noon wrote:
>[snip]
>>> What kind of null statement did you use?
>>>
>>> The JCL null statement is coded as two slashes followed by blanks to the
>>> end of the card image (or column 72 at least).
>>>
>> Two slashes and nothing else; no blanks.  Do I need to have blanks?
>
>I think you will need at least 1 blank. I have never used varying length
>records for JCL, since I date back to the days of Hollerith cards, which
>were always 80 bytes long.
>
What happens to any additional records between the null statement and
the next JOB statement?  are they quietly ignored (with perhaps a message
to operator?)

At what point if any in the logic does the access method recognize INTRDR
as special, different from ordinary SYSOUT?

Does the
//
/*EOF
... that John M. mentioned cause flushing of any SYSOUT or only one with
W=INTRDR?

What happens if the operator issues "$TOJ W=INTRDR" on an ordinary
SYSOUT data set after the fact?

-- gil

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

Re: S0D5 accessing dataspace

[Gary Weinhold]

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 be 
accessible until the job ends.  Rob Scott's suggestion that moving The SYSEVENT 
TRANSWAP before the DSPSERV CREATE is worth trying especially if we can find a 
way to reproduce the abend.

If the abend recurs at this site (or anywhere else), I will surely get the 
output of a D J and an SVCDUMP.

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.



Gary Weinhold
Senior Application Architect

DATAKINETICS | Data Performance & Optimization

Phone:  +1.613.523.5500 x216
Email:  weinh...@dkl.com

[http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]

Visit us online at www.DKL.com

[http://www.dkl.com/wp-content/uploads/2015/08/banner.png]

E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.



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

JCL null statement (Was: job output into dataset

[David W Noon]

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 statement did you use?

The JCL null statement is coded as two slashes followed by blanks to the
end of the card image (or column 72 at least).


Two slashes and nothing else; no blanks.  Do I need to have blanks?


I think you will need at least 1 blank. I have never used varying length 
records for JCL, since I date back to the days of Hollerith cards, which 
were always 80 bytes long.

--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



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

Re: job output into dataset

[Paul Gilmartin]

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 a job and the 
>contents of JESJCLIN ends with the last statement before the
>null JCL statement.
>
What command(s) did you use to submit it?

Does the SDSD SJ command show the same?

I probably observed this in a job submitted by FTP.

-- gil

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

Re: job output into dataset

[Paul Gilmartin]

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 +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 null statement and SDSF shows me
>> those lines in JESJCLIN, indicating that the job was not spun until
>> the SYSOUT was closed.
>
>What kind of null statement did you use?
>
>The JCL null statement is coded as two slashes followed by blanks to the
>end of the card image (or column 72 at least).
>
Two slashes and nothing else; no blanks.  Do I need to have blanks?

-- gil

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

Re: job output into dataset

[David W Noon]

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" 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 null statement and SDSF shows me
those lines in JESJCLIN, indicating that the job was not spun until
the SYSOUT was closed.


What kind of null statement did you use?

The JCL null statement is coded as two slashes followed by blanks to the 
end of the card image (or column 72 at least).

--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: job output into dataset

[J R]

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 interface. This
> allows the use of the "VSAM" ENDREQ macro, which also closes out a job.

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

Re: job output into dataset

[John McKown]

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 null statement;
> >...
> I'm skeptical about that point since I often submit jobs with noise
> such as comments after a null statement and SDSF shows me
> those lines in JESJCLIN, indicating that the job was not spun until
> the SYSOUT was closed.
>

​Being weird (as is well know here), I have the following two JCL
statements last:

//
/*EOF

ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab500/iea3b5_Destination_control_to_internal_reader.htm
​
​*Sending internal reader buffer directly to JES*
Instead of waiting for the buffer in your address space to fill up, send
the contents of the internal reader buffer directly to JES by coding as the
last record in the job:/*EOFThis control statement delimits the job in the
data set and makes it eligible for immediate processing./*DELThis control
statement cancels the job in the data set and schedules it for immediate
output processing. The output consists of any JCL submitted, followed by a
message indicating that the job was deleted before execution./*PURGE*For
JES2 only*, this control statement cancels the job in the data set and
schedules it for purge processing; no output is produced for the job./*SCAN*For
JES2 only*, this control statement requests that JES2 only scan the job in
the data set for JCL errors. The job is not to be executed.
​
​Also, any more, I use the ACB interface instead of the DCB interface. This
allows the use of the "VSAM" ENDREQ macro, which also closes out a job.
This latter is even better since the JCL "null" and the /*EOF could both be
"swallowed up" by something like:

//SYSIN DD DATA,DLM=$$


as the last JCL statement.
ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.hasc300/has2z1_Submitting_to_the_internal_reader_from_jobs_or_tasks.htm


>
> -- gil
>


-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

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

Re: job output into dataset

[Tom Marchant]

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 shows me
>those lines in JESJCLIN, indicating that the job was not spun until
>the SYSOUT was closed.

I don't believe it.

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 a job and the 
contents of JESJCLIN ends with the last statement before the
null JCL statement.

-- 
Tom Marchant

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

Re: job output into dataset

[Paul Gilmartin]

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 null statement and SDSF shows me
those lines in JESJCLIN, indicating that the job was not spun until
the SYSOUT was closed.

-- gil

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

Re: job output into dataset

[Paul Gilmartin]

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.
>
>If an INTRDR stream does not release the job stream to the input spool
>then the submitter program is incorrectly coded.
>
It's pretty hard to commit that error since at least for (iii) the CLOSE is
automatic when the program terminates.

(Well, yes, I've done it by FREEMAINing BSAM buffers prematurely.
But I know better now.)

-- gil

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

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

[Paul Gilmartin]

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 program, and IIRC it 
> was compiled for execution.  Fun stuff.
> 
> Shell scripts are all well and good for those who understand them I suppose, 
> but they have their quirks and deficiencies too.  I can read and write them 
> myself, but many application programmers cannot yet do so, and are stuck with 
> JCL.
>  
Don't consider a deficit of knowledge an insurmountable obstacle.

For z/OS, Rexx might be a better fit than sh.

What JCL facilities are absent from most other languages?:

o Atomic and persistent ENQ SYSDSN to avoid deadlocks.

o Passed data sets/referbacks.

o DISP=RETAIN.

o Other (specify)?

-- gil

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

Re: job output into dataset

[David W Noon]

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 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 JOB statement boundary.


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.

If an INTRDR stream does not release the job stream to the input spool 
then the submitter program is incorrectly coded.

--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

Re: job output into dataset

[Paul Gilmartin]

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 JOB statement boundary.

-- gil

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

Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY

[retired mainframer]

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

When you close the file in CICS, is the enqueue released?  If so, the SHARE 
option is irrelevant since no one else is accessing the dataset.  Unless OAM is 
VSAM under the covers (like PDSE and ZFS), the quoted text states that is does 
apply.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Tuesday, May 09, 2017 9:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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: IBM-MAIN@LISTSERV.UA.EDU
>  Received: Tuesday, May 9, 2017, 10:19 AM
> 
>  > -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 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 exclusive; you
>  cannot specify these keywords
>  >
>  together.
>  > Do not specify DELETE if you
>  specify SHARE. You must have exclusive control
>  > over data sets that are to be deleted;
>  SHARE does not require such exclusive
>  >
>  control.
>  > Note: Unlike the RESTORE
>  command, the COPY command honors the SHARE
>  > keyword for VSAM data sets. However, the
>  SHARE keyword is only honored for
>  > VSAM
>  data sets that were defined with share options other than
>  (1,3) or (1,4).
>  > Specifying the SHARE
>  keyword does not cause DFSMSdss to honor the share
>  > options that are defined for VSAM data
>  sets. For VSAM data sets that are defined
>  > with share options other than (1,3) or
>  (1,4), specifying the SHARE keyword allows
>  > other programs to obtain read access. It
>  does not, however, allow write access to
>  > the data sets while they are being copied.
>  For VSAM data sets that are defined
>  >
>  with share options (1,3) or (1,4), neither read access nor
>  write access by other
>  > programs is
>  allowed while the data set is being copied.
>  >
>  > If my understanding
>  is correct the SHARE parm applis to VSAM dsns which are
>  defined
>  > with share options (2,3) .
>  However the dsn in question is that it is an OAM file.
>  Would the
>  > SHARE apply to OAM dsns as
>  well?
> 
>  The paragraph that
>  talks about VSAM datasets I emphasizing the difference
>  between COPY and RESTORE.  Since your dataset is not VSAM,
>  the paragraph does not apply.  Note the following quote
>  from the Data Set Serialization section of the
>  manual"
> 
>  " The
>  SHARE option has unique properties when applied to the
>  following commands:
>  * For the RESTORE
>  command, SHARE applies to non-VSAM data sets only.
>  * For the DUMP and COPY commands, SHARE
>  applies to non-VSAM data sets and VSAM data sets that are
>  defined with share options other than (1,3) and
>  (1,4)."
> 
>  > Before
>  the COPY is executed the file is closed on CICS.  However
>  after the COPY step
>  > has executed of the
>  dsn (no warnings or errors received)  the job abends at the
>  following
>  > step which tries to enable
>  the file on CICS because the dsn is not released from the
>  job until
>  > it completes.  The job has 6
>  steps.
>  > My question is
>  shouldn''t the dsn be released after the COPY step
>  is has completed or does
>  > dsn is
>  released at the end ot the job?  Could someone please clear
>  this up for me?
> 
>  Does the
>  DSN appear anywhere else in the JCL for the job?  Did a
>  previous step in the job reference the DSN during
>  execution?

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

Re: AW: Re: job output into dataset

[Lizette Koehler]

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 certain amount you 
will see S722 abends

When you SPIN output it will go to the output class specified.

For example, SYSOUT=B -  When you spin it will go to the class B.  Now if B is 
setup in JES2 as a HELD class or OUTPUT class is dependent on your shop's JES2 
parm

You can see the output that you SPIN in the SDSF Panels.  Either theOST 
   H   panels

Once you spin the output you still need another process to write the data to a 
data set.

Processes suggested so far
 Write an SDSF ISFEXEC REXX to read the Data from JES2 to dataset _ Example 
is JES2DISK
 Purchase a product to do this ($AVERS, VIEW DIRECT, XPTR, and so forth)
 Setup and External writer to read the data from Spool and write to a 
dataset
 Setup a JES2 Offloader to write the data to a dataset.
 Look for tools on cbttape.org



Note:  There are special DD statements that are generated by JES2 you cannot 
control with a JCL Statement to spin it.

You could review the Manuals  JES2 INIT and TUNING GUIDE, and JES2 INIT and 
TUNING Reference.  They have good detail on how JES2 does output management.

SA32-0991-00z/OS JES2 Initialization and Tuning Guide
SA32-0992-00z/OS JES2 Initialization and Tuning Reference

Next, find the REXX called JES2DISK.  I use this all the time to read data from 
JES2 and write it to a dataset.  It works very well.


It is still not clear what problem you are trying to solve.


If you could summarize what it is you need to do, it might be helpful to level 
set the issue at this time.  There have been a lot of comments and suggestions 
which do not seem to meet your needs. 

For example, my task needs to collect the data from STC x which runs 24x7.  I 
need the information written to the DD statement Y.  This needs to go into a 
GDG or SEQ files for later review.  This output is a (REPORT, JCL, LOGGING, 
etc) 



SPIN can happen at the TASK LEVEL -  S stcname,SPIN=('spin parms') 
  Or the DD level  //DD  DD SYSOUT=x,SPIN=  
  OR by issuing a JES2 command  $Tzz,SPINzzz is either Task Number, 
TaskName

Depending on the requirements you are provided, it will depend on which 
function you will need to use.


The more specific the question, the better the answers.  Generic questions or 
comments can lead to confusion for everyone.

This list can provide lots of suggestions and guidance.  It will be your job to 
work with the suggestions and see what works in your shop.  Each shop is 
different and what works for one does not always work for another.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of venkat kulkarni
> Sent: Tuesday, May 09, 2017 12:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 to remove those many record from JESMSGLG
> dd which we just spin .
> 
> On 09-May-2017 9:40 AM, "Gibney, Dave"  wrote:
> 
> > 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: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: AW: Re: job output into dataset
> > >
> > > Hello All,
> > >
> > >
> > >
> > > Thanks for reply. I looked at my IMS proc and looks like below.
> > >
> > >
> > >
> > > BROWSESYS1.DEVL.PROCLIB(IMS12IMS) - 01.05Line  Col
> > 001
> > > 080
> > >
> > >  Command ===>  Scroll
> > ===>
> > > CSR
> > >
> > > * Top of Data
> > > **
> > > 
> > >
> > > //   PROC RGN=0M,SOUT=A,
> > >
> > > //SYS=,SYS2=,
> > >
> > > //RGSUF=DBC,PARM1='AUTO=N',
> > >
> > > //PARM2=
> > >
> > > //IEFPROC EXEC PGM=DFSMVRC0,REGION=,
> > >
> > > //PARM='DBC,,,'
> > >
> > > //*
> > >
> > > //STEPLIB  DD DSN=IMS1.V120.,DISP=SHR
> > >
> > > //PROCLIB  DD DSN=IMS1.V120.,DISP=SHR
> > >
> > > //*
> > >
> > > //IMSIRD   DD SYSOUT=(A,INTRDR)
> > >
> > > //*
> > >
> > > //*
> > >
> > > //DFSOLP00 DD DSN=IMS1.V120.,DISP=SHR
> > >
> > > //DFSOLP01 DD DSN=IMS1.V120.,DISP=SHR
> > >
> > > //DFSOLP99 

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

[Peter Hunkeler]

> 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 email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Jim Mulder]

  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 frames for all processors 
> as part of recovery processing to invoke the ESTAE? If so, I can 
> ignore them since the are not part of the problem.



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

Re: BUILDMCS fallout

[Jesse 1 Robinson]

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

My preference for the usermod would be 

-- Rework/rewrite the usermod for the new environment, including DISTLIB even 
though you don't plan to ACCEPT it. Give it a current rework date to make sure 
it gets RECEIVEd. Most important, PRE all the PTFs that have hit the COBOL 
options module during the life of the FMID. 

-- RECEIVE and APPLY the updated usermod. At this point all relevant entries 
should be correct without further tweaking. 

-- If you need to install a subsequent PTF that hits the options module, rework 
the usermod again with a new REWORK date and a PRE for the new PTF. This 
procedure can be used for any normal install.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, May 09, 2017 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Schramm
Sent: Tuesday, May 09, 2017 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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:

> 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
> Subject: 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
> zones.   The BUILDMCS, and follow-on's to receive and apply into the new
> zones went fine.  However, my usermod for setting default options(MCOB001)
> somehow got SUP'd by FMID for COBOL.   I've been able to overcome this by
> coming up with a new usermod name, and having it PRE(MCOB001), but if 
> at all possible, I'd like to get this fixed.  The usermod wasn't 
> ACCEPTED in its prior zones, so not exactly sure how this happened.
>
> From the target zone, and oddly, shows the same for the COBOL DLIB 
> zone as well.  Is there a way to remove this relationship?  MCOB001 is not 
> applied.
>
> Primary Command: FIND
>
> Entry Type:  SYSMOD  Zone Name: MVSCBT
> Entry Name:  MCOB001 Zone Type: TARGET
> Description:
>
>   Type:  Status:
>   FMID:  SUPBY   HADB420
>   Date/Time:
>
> _
> 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

Rob Schramm

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

Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY

[willie bunter]

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: IBM-MAIN@LISTSERV.UA.EDU
 Received: Tuesday, May 9, 2017, 10:19 AM
 
 > -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 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 exclusive; you
 cannot specify these keywords
 >
 together.
 > Do not specify DELETE if you
 specify SHARE. You must have exclusive control
 > over data sets that are to be deleted;
 SHARE does not require such exclusive
 >
 control.
 > Note: Unlike the RESTORE
 command, the COPY command honors the SHARE
 > keyword for VSAM data sets. However, the
 SHARE keyword is only honored for
 > VSAM
 data sets that were defined with share options other than
 (1,3) or (1,4).
 > Specifying the SHARE
 keyword does not cause DFSMSdss to honor the share
 > options that are defined for VSAM data
 sets. For VSAM data sets that are defined
 > with share options other than (1,3) or
 (1,4), specifying the SHARE keyword allows
 > other programs to obtain read access. It
 does not, however, allow write access to
 > the data sets while they are being copied.
 For VSAM data sets that are defined
 >
 with share options (1,3) or (1,4), neither read access nor
 write access by other
 > programs is
 allowed while the data set is being copied.
 > 
 > If my understanding
 is correct the SHARE parm applis to VSAM dsns which are
 defined
 > with share options (2,3) . 
 However the dsn in question is that it is an OAM file. 
 Would the
 > SHARE apply to OAM dsns as
 well?
 
 The paragraph that
 talks about VSAM datasets I emphasizing the difference
 between COPY and RESTORE.  Since your dataset is not VSAM,
 the paragraph does not apply.  Note the following quote
 from the Data Set Serialization section of the
 manual"
 
 " The
 SHARE option has unique properties when applied to the
 following commands:
     * For the RESTORE
 command, SHARE applies to non-VSAM data sets only.
     * For the DUMP and COPY commands, SHARE
 applies to non-VSAM data sets and VSAM data sets that are
 defined with share options other than (1,3) and
 (1,4)."
 
 > Before
 the COPY is executed the file is closed on CICS.  However
 after the COPY step
 > has executed of the
 dsn (no warnings or errors received)  the job abends at the
 following
 > step which tries to enable
 the file on CICS because the dsn is not released from the
 job until
 > it completes.  The job has 6
 steps.
 > My question is
 shouldn''t the dsn be released after the COPY step
 is has completed or does
 > dsn is
 released at the end ot the job?  Could someone please clear
 this up for me?
 
 Does the
 DSN appear anywhere else in the JCL for the job?  Did a
 previous step in the job reference the DSN during
 execution?
 
 --
 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 System symbols

[Johnson, Timothy@CIO]

-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 is an 
> excellent chart at
 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.2.0%2Fcom.ibm.zos.v2r2.ieae200%Fdynpsm.htm=02%7C01%7CTimothy.Johnson%40STATE.CA.GOV%7C3e73d953f08f4b45043908d494aaa950%7C52b26be47f5d4e1cbaed8cf75b7570d5%7C1%7C07C636296908099559181=NL0uYqX5MA8ig2JU%2FjZS2QL85aRFO5ku%2B4pHRwU95vE%3D=0





Excellent looks different to me! The table still shows the, at least on z/OS V 
2.1 and up, invalid symbols  and  And all the local date/time 
related symbols are only mentioned in the explanation of other symbols. Rubbish.


--
Peter Hunkeler

 




--
Peter Hunkeler 

--
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: AW: Re: job output into dataset

[Farley, Peter x23353]

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.

Shell scripts are all well and good for those who understand them I suppose, 
but they have their quirks and deficiencies too.  I can read and write them 
myself, but many application programmers cannot yet do so, and are stuck with 
JCL.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, May 09, 2017 11:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AW: Re: job output into dataset



IMO, IBM needs to _replace_ JCL with "something else". But, honestly, I'm not 
knowledgeable enough to design the "something else". And, even then, you'd need 
to allow both the old JCL and the new WCL (Workload Control Language, just to 
give it a name) to be "submitted". But, also quite honestly, I'd really prefer 
that IBM use its time and money for better things. If you don't like JCL (and I 
don't really), then just run UNIX scripts via JCL using Dovetailed 
Technologies' Co:Z Launcher. It has the nice property of being able to allow 
the reading and writing of physical sequential data sets defined in DDs using 
their "fromdsn" and "todsn" UNIX commands.

--


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


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

Re: Interesting article on UNICODE.

[Charles Mills]

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 strings have a fixed byte length.

In any event I did not mean to imply that no one have ever thought of or 
implemented the concept of UTF-8 externally/UTF-something else internally. I 
was just throwing the idea out there.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jack J. Woehr
Sent: Monday, May 8, 2017 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Interesting article on UNICODE.

Charles Mills wrote:
> What about a language concept where data was externalized as UTF-8 but 
> presented to the program logic internally as UTF-32? With automatic, 
> transparent re-encoding back-and-forth for externalization?

What about coding in Java? :)

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

Re: Merging SYSPLEXes Information....

[Jesse 1 Robinson]

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 user stuff up to 
catalog names. 

My first foray into LPAR merge was way before sysplex. Two LPARs in two data 
centers needed to become one. Everything was owned by the same folks, but the 
history of the two centers had diverged years earlier. There were 
(conservatively) hundreds of identically named data sets A.B.C in both centers. 
Some pairs may have had identical content, others not despite the same name and 
same owner. When you merge, every single collision must be investigated 
*individually* and resolved: keep #1, keep #2, keep both under different names. 
There is no formulaic answer. 

Fast forward to post Y2K. We were compelled to merge two sysplexes for 
licensing reasons. Again, all the same ownership but historically diverse. The 
deadline was imminent. No one wanted to spend umpty-ump dollars on a task with 
no business case other than PSLC charges. So we created a 'bronze-plex', 
parallel sysplex for SMF/RMF purposes but still functionally separate for most 
practical purposes. I will spare you the details of surviving such an activity 
unless you really need to learn more.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cameron Conacher
Sent: Tuesday, May 09, 2017 8:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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, 2017 at 9:59 AM, Elardus Engelbrecht < 
elardus.engelbre...@sita.co.za> wrote:

> 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 one site or not?
>
>
> >Once I collapse say SYSPLEX#7 into SYSPLEX #1, all of SYSPLEX #7 data
> would available to SYSPLEX #1, so it would be much easier to migrate 
> workloads from one LPAR to another. When I use my old friend Google, I 
> get lots of hits on creating a SYSPLEX, but I wanted to be able to 
> merge two SYSPLEXes into one.
>
> Perhaps you should start looking which Sysplex is the surviving one 
> and then bring all the LPARs of one Sysplex into that. When finished, 
> move on to the next Sysplex and all their LPARs. And so on with the other 
> Sysplexes.
>
>
> >Can someone point me to some information I could read through that 
> >would
> help me get my arms around this one?
>
> What about this Redbook 'Merging Systems into a Sysplex' in
>
> http://www.redbooks.ibm.com/abstracts/sg246818.html?Open ?
>
> Groete / Greetings
> Elardus Engelbrecht


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

Re: BUILDMCS fallout

[Jousma, David]

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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Schramm
Sent: Tuesday, May 09, 2017 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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:

> 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
> Subject: 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
> zones.   The BUILDMCS, and follow-on's to receive and apply into the new
> zones went fine.  However, my usermod for setting default options(MCOB001)
> somehow got SUP'd by FMID for COBOL.   I've been able to overcome this by
> coming up with a new usermod name, and having it PRE(MCOB001), but if 
> at all possible, I'd like to get this fixed.  The usermod wasn't 
> ACCEPTED in its prior zones, so not exactly sure how this happened.
>
> From the target zone, and oddly, shows the same for the COBOL DLIB 
> zone as well.  Is there a way to remove this relationship?  MCOB001 is not 
> applied.
>
> Primary Command: FIND
>
> Entry Type:  SYSMOD  Zone Name: MVSCBT
> Entry Name:  MCOB001 Zone Type: TARGET
> Description:
>
>   Type:  Status:
>   FMID:  SUPBY   HADB420
>   Date/Time:
>
> _
> 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
>
> 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
>
>
> ::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 

Re: BUILDMCS fallout

[Rob Schramm]

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:

> 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
> Subject: 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
> zones.   The BUILDMCS, and follow-on's to receive and apply into the new
> zones went fine.  However, my usermod for setting default options(MCOB001)
> somehow got SUP'd by FMID for COBOL.   I've been able to overcome this by
> coming up with a new usermod name, and having it PRE(MCOB001), but if at
> all possible, I'd like to get this fixed.  The usermod wasn't ACCEPTED in
> its prior zones, so not exactly sure how this happened.
>
> From the target zone, and oddly, shows the same for the COBOL DLIB zone as
> well.  Is there a way to remove this relationship?  MCOB001 is not applied.
>
> Primary Command: FIND
>
> Entry Type:  SYSMOD  Zone Name: MVSCBT
> Entry Name:  MCOB001 Zone Type: TARGET
> Description:
>
>   Type:  Status:
>   FMID:  SUPBY   HADB420
>   Date/Time:
>
> _
> 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
>
> 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
>
>
> ::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
>
-- 

Rob Schramm

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

Re: job output into dataset

[Paul Gilmartin]

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 ALGOL-68.  But
processing directives are much older.  How long has assembler had a
PRINT directive, very similar in purpose to //* FORMAT?

On JES2-only or JES3-only constructs:

IIRC, there was an interval during which the JCL OUTPUT statement was
supported by JES2 but not by JES3.  What happened at that time if a
programmer attempted to run a JES2 job containing "OUTPUT" on JES3?

o OUTPUT was quietly ignored?

o OUTPUT was ignored except for a warning?

o Syntax error?

I consider the "quietly ignored" behavior the worst

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

Re: BUILDMCS fallout

[Jousma, David]

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) UNIT(3390)) RMID(MCOB001) SYSLIB(SIGYSAMP).   

I suspect this is how COB FMID came to supercede the usermod.  I also had done 
a DEL on the SRC/MOD entries to remove the RMID

_
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-
From: Jousma, David 
Sent: Tuesday, May 09, 2017 11:33 AM
To: 'IBM Mainframe Discussion List'
Subject: 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 longer, that’s why I 
chose to move it to its own zone, so that I can still install maintenance, but 
when we are truly done with the conversion, the removal/cleanup will be just as 
easy.   For us, (well our application teams) it will be an especially difficult 
migration.  I think there are a lot of old "sins" lying around yet, in the form 
of old modules that were compiled under OS/VS cobol, etc.   We've converted 
most of their load libraries to PDS-E with a few exceptions.  

As you say, it's all cleaned up now, and in the moment, it was more of an OCD 
thing, and having everything neat and tidy.   It's more of a curiosity thing at 
this point, but in the end, really doesn’t matter.

Thanks, Dave
_
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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, May 09, 2017 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 picked up. That's 
why it's critical to accept all installed IBM maintenance before running 
BUILDMCS. Usermods are a special problem. Every sentient voice in the SMPE 
world says *never* to accept a usermod. But if it's not accepted, then it will 
get dropped by BUILDMCS. A couple of solutions:

-- Accept the usermod before BUILDMCS. IMHO not a good idea because, well, see 
above.   

-- Do just what you did, then reinstall the usermod in the new zone. Which is 
what you did. In order to reinstall, you need to treat it just as you would in 
a 'normal' environment. However you would handle a PTF that conflicts with a 
usermod, use the same technique here. I have my own preference for that 
process, but you should do what makes sense. I think you're OK now. 

Another question is whether you plan to continue with regular maintenance to 
COBOL 4.2. Depending your timeline calendar, that might be prudent. Or you 
could freeze it as is and plow forward; only an issue if a serious problem 
develops in 4.2 that you have to fix before 6.1 is ready for prime time.  

The status of MCOB001 is a result of your BUILDMCS procedure. I think it's 
purely cosmetic. If you reinstall MCOB001 to resolve the MODID conflict, it 
will look prettier but function the same. 


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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, May 09, 2017 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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
Subject: 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 zones.   The BUILDMCS, and 
follow-on's to 

Re: BUILDMCS fallout

[Jousma, David]

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 longer, that’s why I 
chose to move it to its own zone, so that I can still install maintenance, but 
when we are truly done with the conversion, the removal/cleanup will be just as 
easy.   For us, (well our application teams) it will be an especially difficult 
migration.  I think there are a lot of old "sins" lying around yet, in the form 
of old modules that were compiled under OS/VS cobol, etc.   We've converted 
most of their load libraries to PDS-E with a few exceptions.  

As you say, it's all cleaned up now, and in the moment, it was more of an OCD 
thing, and having everything neat and tidy.   It's more of a curiosity thing at 
this point, but in the end, really doesn’t matter.

Thanks, Dave
_
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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, May 09, 2017 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 picked up. That's 
why it's critical to accept all installed IBM maintenance before running 
BUILDMCS. Usermods are a special problem. Every sentient voice in the SMPE 
world says *never* to accept a usermod. But if it's not accepted, then it will 
get dropped by BUILDMCS. A couple of solutions:

-- Accept the usermod before BUILDMCS. IMHO not a good idea because, well, see 
above.   

-- Do just what you did, then reinstall the usermod in the new zone. Which is 
what you did. In order to reinstall, you need to treat it just as you would in 
a 'normal' environment. However you would handle a PTF that conflicts with a 
usermod, use the same technique here. I have my own preference for that 
process, but you should do what makes sense. I think you're OK now. 

Another question is whether you plan to continue with regular maintenance to 
COBOL 4.2. Depending your timeline calendar, that might be prudent. Or you 
could freeze it as is and plow forward; only an issue if a serious problem 
develops in 4.2 that you have to fix before 6.1 is ready for prime time.  

The status of MCOB001 is a result of your BUILDMCS procedure. I think it's 
purely cosmetic. If you reinstall MCOB001 to resolve the MODID conflict, it 
will look prettier but function the same. 


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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, May 09, 2017 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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
Subject: 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 zones.   The BUILDMCS, and 
follow-on's to receive and apply into the new zones went fine.  However, my 
usermod for setting default options(MCOB001) somehow got SUP'd by FMID for 
COBOL.   I've been able to overcome this by coming up with a new usermod name, 
and having it PRE(MCOB001), but if at all possible, I'd like to get this fixed. 
 The usermod wasn't ACCEPTED in its prior zones, so not exactly sure how this 
happened.

From the target zone, and oddly, shows the same for the COBOL DLIB zone as 
well.  Is there a way to remove this relationship?  MCOB001 is not applied.

Primary Command: FIND

Entry Type:  SYSMOD  Zone Name: MVSCBT
Entry Name:  MCOB001 Zone Type: TARGET
Description:

  Type:  Status:
  FMID:  SUPBY   HADB420
  Date/Time:

_

Re: AW: Re: job output into dataset

[John McKown]

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
> >>//*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 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 either environment.
> >
> I don't consider it a good reason.  It would have been better to provide a
> PRAGMA directive as many other languages do, rather than to usurp
> part of the comment grammar with attendant risk of astonishment.
>

​In a perfect world, you are correct. But JES2 was originally HASP, whereas
JES3 was ASP. And those "products" were non-IBM developed (as not in PID)
"add ons" back in the days of OS/MFT & OS/MVT. Many of the strange things
in JES2 (such as the DUPL_JOB=DELAY) were inherited from HASP. Since they
were "add ons", they could not introduce any changes to the JCL
converter/interpreter. After 40+ years, changing all your old JES{2,3} JECL
to the "new and improved!" stuff would cause people to tear IBM a new one.
One big problem with z/OS is all the "cruft" left over from restriction in
the past which were _required_ (due to the "smallness" of the computers) at
the time but are now just a PITA.​

IMO, IBM needs to _replace_ JCL with "something else". But, honestly, I'm
not knowledgeable enough to design the "something else". And, even then,
you'd need to allow both the old JCL and the new WCL (Workload Control
Language, just to give it a name) to be "submitted". But, also quite
honestly, I'd really prefer that IBM use its time and money for better
things. If you don't like JCL (and I don't really), then just run UNIX
scripts via JCL using Dovetailed Technologies' Co:Z Launcher. It has the
nice property of being able to allow the reading and writing of physical
sequential data sets defined in DDs using their "fromdsn" and "todsn" UNIX
commands.



>
> -- gil
>
>

-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

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

Re: AW: Re: job output into dataset

[Tom Marchant]

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 either environment.
>> 
>I don't consider it a good reason.  It would have been better to provide a
>PRAGMA directive as many other languages do, rather than to usurp
>part of the comment grammar with attendant risk of astonishment.

Hindsight.

How many languages had a PRAGMA directive when ASP was written in the 1960's?

-- 
Tom Marchant

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

Re: BUILDMCS fallout

[Jesse 1 Robinson]

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 picked up. That's 
why it's critical to accept all installed IBM maintenance before running 
BUILDMCS. Usermods are a special problem. Every sentient voice in the SMPE 
world says *never* to accept a usermod. But if it's not accepted, then it will 
get dropped by BUILDMCS. A couple of solutions:

-- Accept the usermod before BUILDMCS. IMHO not a good idea because, well, see 
above.   

-- Do just what you did, then reinstall the usermod in the new zone. Which is 
what you did. In order to reinstall, you need to treat it just as you would in 
a 'normal' environment. However you would handle a PTF that conflicts with a 
usermod, use the same technique here. I have my own preference for that 
process, but you should do what makes sense. I think you're OK now. 

Another question is whether you plan to continue with regular maintenance to 
COBOL 4.2. Depending your timeline calendar, that might be prudent. Or you 
could freeze it as is and plow forward; only an issue if a serious problem 
develops in 4.2 that you have to fix before 6.1 is ready for prime time.  

The status of MCOB001 is a result of your BUILDMCS procedure. I think it's 
purely cosmetic. If you reinstall MCOB001 to resolve the MODID conflict, it 
will look prettier but function the same. 


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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, May 09, 2017 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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
Subject: 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 zones.   The BUILDMCS, and 
follow-on's to receive and apply into the new zones went fine.  However, my 
usermod for setting default options(MCOB001) somehow got SUP'd by FMID for 
COBOL.   I've been able to overcome this by coming up with a new usermod name, 
and having it PRE(MCOB001), but if at all possible, I'd like to get this fixed. 
 The usermod wasn't ACCEPTED in its prior zones, so not exactly sure how this 
happened.

From the target zone, and oddly, shows the same for the COBOL DLIB zone as 
well.  Is there a way to remove this relationship?  MCOB001 is not applied.

Primary Command: FIND

Entry Type:  SYSMOD  Zone Name: MVSCBT
Entry Name:  MCOB001 Zone Type: TARGET
Description:

  Type:  Status:
  FMID:  SUPBY   HADB420
  Date/Time:

_
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


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

Re: Merging SYSPLEXes Information....

[Cameron Conacher]

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, 2017 at 9:59 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> 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 one site or not?
>
>
> >Once I collapse say SYSPLEX#7 into SYSPLEX #1, all of SYSPLEX #7 data
> would available to SYSPLEX #1, so it would be much easier to migrate
> workloads from one LPAR to another. When I use my old friend Google, I get
> lots of hits on creating a SYSPLEX, but I wanted to be able to merge two
> SYSPLEXes into one.
>
> Perhaps you should start looking which Sysplex is the surviving one and
> then bring all the LPARs of one Sysplex into that. When finished, move on
> to the next Sysplex and all their LPARs. And so on with the other Sysplexes.
>
>
> >Can someone point me to some information I could read through that would
> help me get my arms around this one?
>
> What about this Redbook 'Merging Systems into a Sysplex' in
>
> http://www.redbooks.ibm.com/abstracts/sg246818.html?Open ?
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: AW: Re: job output into dataset

[Paul Gilmartin]

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!)
>
>It's a JES3 JECL statement.
>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 either environment.
> 
I don't consider it a good reason.  It would have been better to provide a
PRAGMA directive as many other languages do, rather than to usurp
part of the comment grammar with attendant risk of astonishment.

-- gil

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

Re: BUILDMCS fallout

[Allan Staller]

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 HADB610 
contains ++DELETES for the old releases.

HADB400  DELETED   FUNCTION
   
HADB420  DELETED   FUNCTION
   
HADB510  DELETED   FUNCTION
   
HADB520  DELETED   FUNCTION
   
HADB610  APPLIED   FUNCTION  HADB610  IFREQUI43370



I was able to fix the problem however with some simple UCLIN.

UCLIN .
   DEL SYSMOD(MCOB001). 
 ENDUCL .   
 SET   BOUNDARY (MVSCBD).   
 UCLIN .
   DEL SYSMOD(MCOB001). 
 ENDUCL .   


After which I was able to receive, and apply.   So life is good.
_
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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, May 09, 2017 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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
Subject: 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 zones.   The BUILDMCS, and 
follow-on's to receive and apply into the new zones went fine.  However, my 
usermod for setting default options(MCOB001) somehow got SUP'd by FMID for 
COBOL.   I've been able to overcome this by coming up with a new usermod name, 
and having it PRE(MCOB001), but if at all possible, I'd like to get this fixed. 
 The usermod wasn't ACCEPTED in its prior zones, so not exactly sure how this 
happened.

>From the target zone, and oddly, shows the same for the COBOL DLIB zone as 
>well.  Is there a way to remove this relationship?  MCOB001 is not applied.

Primary Command: FIND

Entry Type:  SYSMOD  Zone Name: MVSCBT
Entry Name:  MCOB001 Zone Type: TARGET
Description:

  Type:  Status:
  FMID:  SUPBY   HADB420
  Date/Time:

_
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

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


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

Re: AW: Re: job output into dataset

[John McKown]

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 recycle ims and then issue
> > $t job,imsproc,spin,ddname=JESMSGLG
> > Command to spin JESMSGLG.
> >
> The JCL Ref. lists several DDNAMES not available for general use:
> Special ddnames
> The special data sets are identified by the following ddnames:
> JOBLIB
> STEPLIB
> SYSABEND
> SYSCHK
> SYSCKEOV
> SYSIN
> SYSMDUMP
> SYSUDUMP
>
> SDSF also shows me several (pseudo?) DDNAMEs such as
> JESJCL, JESYSMSG, and JESMSGLG.  What happens if the
> programmer attempts to override one of these, e.g. by
> directing it to a catalogued data set or a UNIX file?
>

​NCD - No Can Do. Those pseudo DDNAMEs cannot be directed to a non-SPOOL
data set or UNIX file. The only thing that I know could possibly be done is
to SPIN them off periodically (or aperiodically "as requested" via that $T
command) and then process the spun data, perhaps into a DSN or UNIX file
or, as we do, to a "remote" location via an LPR destination (which is a
Windows box driven from z/OS via MacKinney's JQP).



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

​this is a JES3 JECL (JEs Command Language) statement. And, yes, it _is_
also a regular JCL comment statement in a non-JES3 (i.e. JES2) environment.​



>
> -- gil
>
>
-- 
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

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

Re: AW: Re: job output into dataset

[Tom Marchant]

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

-- 
Tom Marchant

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

Re: BUILDMCS fallout

[Jousma, David]

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
   
HADB510  DELETED   FUNCTION
   
HADB520  DELETED   FUNCTION
   
HADB610  APPLIED   FUNCTION  HADB610  IFREQUI43370



I was able to fix the problem however with some simple UCLIN.

UCLIN .
   DEL SYSMOD(MCOB001). 
 ENDUCL .   
 SET   BOUNDARY (MVSCBD).   
 UCLIN .
   DEL SYSMOD(MCOB001). 
 ENDUCL .   


After which I was able to receive, and apply.   So life is good.
_
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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, May 09, 2017 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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
Subject: 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 zones.   The BUILDMCS, and 
follow-on's to receive and apply into the new zones went fine.  However, my 
usermod for setting default options(MCOB001) somehow got SUP'd by FMID for 
COBOL.   I've been able to overcome this by coming up with a new usermod name, 
and having it PRE(MCOB001), but if at all possible, I'd like to get this fixed. 
 The usermod wasn't ACCEPTED in its prior zones, so not exactly sure how this 
happened.

>From the target zone, and oddly, shows the same for the COBOL DLIB zone as 
>well.  Is there a way to remove this relationship?  MCOB001 is not applied.

Primary Command: FIND

Entry Type:  SYSMOD  Zone Name: MVSCBT
Entry Name:  MCOB001 Zone Type: TARGET
Description:

  Type:  Status:
  FMID:  SUPBY   HADB420
  Date/Time:

_
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

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


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

Re: BUILDMCS fallout

[Allan Staller]

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
Subject: 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 zones.   The BUILDMCS, and 
follow-on's to receive and apply into the new zones went fine.  However, my 
usermod for setting default options(MCOB001) somehow got SUP'd by FMID for 
COBOL.   I've been able to overcome this by coming up with a new usermod name, 
and having it PRE(MCOB001), but if at all possible, I'd like to get this fixed. 
 The usermod wasn't ACCEPTED in its prior zones, so not exactly sure how this 
happened.

>From the target zone, and oddly, shows the same for the COBOL DLIB zone as 
>well.  Is there a way to remove this relationship?  MCOB001 is not applied.

Primary Command: FIND

Entry Type:  SYSMOD  Zone Name: MVSCBT
Entry Name:  MCOB001 Zone Type: TARGET
Description:

  Type:  Status:
  FMID:  SUPBY   HADB420
  Date/Time:

_
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

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


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

BUILDMCS fallout

[Jousma, David]

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 zones.   The BUILDMCS, and 
follow-on's to receive and apply into the new zones went fine.  However, my 
usermod for setting default options(MCOB001) somehow got SUP'd by FMID for 
COBOL.   I've been able to overcome this by coming up with a new usermod name, 
and having it PRE(MCOB001), but if at all possible, I'd like to get this fixed. 
 The usermod wasn't ACCEPTED in its prior zones, so not exactly sure how this 
happened.

>From the target zone, and oddly, shows the same for the COBOL DLIB zone as 
>well.  Is there a way to remove this relationship?  MCOB001 is not applied.

Primary Command: FIND

Entry Type:  SYSMOD  Zone Name: MVSCBT
Entry Name:  MCOB001 Zone Type: TARGET
Description:

  Type:  Status:
  FMID:  SUPBY   HADB420
  Date/Time:

_
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

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: AW: Re: job output into dataset

[Tom Marchant]

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

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

Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY

[retired mainframer]

> -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 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 exclusive; you cannot specify these keywords
> together.
> Do not specify DELETE if you specify SHARE. You must have exclusive control
> over data sets that are to be deleted; SHARE does not require such exclusive
> control.
> Note: Unlike the RESTORE command, the COPY command honors the SHARE
> keyword for VSAM data sets. However, the SHARE keyword is only honored for
> VSAM data sets that were defined with share options other than (1,3) or (1,4).
> Specifying the SHARE keyword does not cause DFSMSdss to honor the share
> options that are defined for VSAM data sets. For VSAM data sets that are 
> defined
> with share options other than (1,3) or (1,4), specifying the SHARE keyword 
> allows
> other programs to obtain read access. It does not, however, allow write 
> access to
> the data sets while they are being copied. For VSAM data sets that are defined
> with share options (1,3) or (1,4), neither read access nor write access by 
> other
> programs is allowed while the data set is being copied.
> 
> If my understanding is correct the SHARE parm applis to VSAM dsns which are 
> defined
> with share options (2,3) .  However the dsn in question is that it is an OAM 
> file.  Would the
> SHARE apply to OAM dsns as well?

The paragraph that talks about VSAM datasets I emphasizing the difference 
between COPY and RESTORE.  Since your dataset is not VSAM, the paragraph does 
not apply.  Note the following quote from the Data Set Serialization section of 
the manual"

" The SHARE option has unique properties when applied to the following commands:
* For the RESTORE command, SHARE applies to non-VSAM data sets only.
* For the DUMP and COPY commands, SHARE applies to non-VSAM data sets and 
VSAM data sets that are defined with share options other than (1,3) and (1,4)."

> Before the COPY is executed the file is closed on CICS.  However after the 
> COPY step
> has executed of the dsn (no warnings or errors received)  the job abends at 
> the following
> step which tries to enable the file on CICS because the dsn is not released 
> from the job until
> it completes.  The job has 6 steps.
> My question is shouldn''t the dsn be released after the COPY step is has 
> completed or does
> dsn is released at the end ot the job?  Could someone please clear this up 
> for me?

Does the DSN appear anywhere else in the JCL for the job?  Did a previous step 
in the job reference the DSN during execution?

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

Re: AW: Re: job output into dataset

[Paul Gilmartin]

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 several DDNAMES not available for general use:
Special ddnames
The special data sets are identified by the following ddnames:
JOBLIB 
STEPLIB 
SYSABEND 
SYSCHK 
SYSCKEOV 
SYSIN 
SYSMDUMP 
SYSUDUMP

SDSF also shows me several (pseudo?) DDNAMEs such as
JESJCL, JESYSMSG, and JESMSGLG.  What happens if the
programmer attempts to override one of these, e.g. by
directing it to a catalogued data set or a UNIX file?

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

-- gil

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

Re: IBM Doc Buddy V1.3.0 supports online search

[Beesley, Paul]

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 supports online search

IBM Doc Buddy V1.3 is now available for download in Apple App Store and Google 
Play. IBM Doc Buddy is a mobile app which enables retrieving product error 
messages of IBM z Systems products.

This release includes major search enhancements:
* The app now supports online search in addition to offline search. You can get 
instant search results if you are connected to the Internet. Online search is 
enabled by default in Settings.

* An overview of the app features is provided for first-time app users to help 
you get started. After you install the app, you can take a quick glance at the 
handy 3-panel display to understand the key features provided in IBM Doc Buddy.

* Messages of these products are added: Tivoli OMEGAMON for Storage on z/OS and 
Tivoli OMEGAMON XE on z/VM and Linux.

Further information
* Blog about V1.3 enhancements: 
https://developer.ibm.com/mainframe/2017/05/05/ibm-doc-buddy-v1-3-0-available-mobile-app-search-error-messages-right-away/

* IBM Doc Buddy email: spt...@cn.ibm.com

* IBM Doc Buddy home page: https://ibmdocbuddy.mybluemix.net/

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
names used by the Atos group. The following trading entities are registered in 
England and Wales: Atos IT Services UK Limited (registered number 01245534), 
Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited 
(registered number 08514184) and Canopy The Open Cloud Company Limited 
(registration number 08011902). The registered office for each is at 4 Triton 
Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

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

Re: Merging SYSPLEXes Information....

[Elardus Engelbrecht]

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 one site or not?


>Once I collapse say SYSPLEX#7 into SYSPLEX #1, all of SYSPLEX #7 data would 
>available to SYSPLEX #1, so it would be much easier to migrate workloads from 
>one LPAR to another. When I use my old friend Google, I get lots of hits on 
>creating a SYSPLEX, but I wanted to be able to merge two SYSPLEXes into one.

Perhaps you should start looking which Sysplex is the surviving one and then 
bring all the LPARs of one Sysplex into that. When finished, move on to the 
next Sysplex and all their LPARs. And so on with the other Sysplexes.


>Can someone point me to some information I could read through that would help 
>me get my arms around this one?

What about this Redbook 'Merging Systems into a Sysplex' in 

http://www.redbooks.ibm.com/abstracts/sg246818.html?Open ?

Groete / Greetings
Elardus Engelbrecht

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

Re: Merging SYSPLEXes Information....

[Allan Staller]

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 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 SYSPLEX #7 data would 
available to SYSPLEX #1, so it would be much easier to migrate workloads from 
one LPAR to another.

When I use my old friend Google, I get lots of hits on creating a SYSPLEX, but 
I wanted to be able to merge two SYSPLEXes into one.



::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: Merging SYSPLEXes Information....

[Vernooij, Kees (ITOPT1) - KLM]

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 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cameron Conacher
> Sent: 09 May, 2017 15:39
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 SYSPLEX #7 data
> would
> available to SYSPLEX #1, so it would be much easier to migrate workloads
> from one LPAR to another.
> 
> When I use my old friend Google, I get lots of hits on creating a
> SYSPLEX,
> but I wanted to be able to merge two SYSPLEXes into one.
> 
> Can someone point me to some information I could read through that would
> help me get my arms around this one?
> 
> Thanks,
> 
> ...Cameron
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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



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

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

[Peter Hunkeler]

 
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
After the program check 00A (PGM 00A) the program check interrupt handler is 
invoked (RCVY PROG). It hands over to the ESTAE routine (SVC D and RCVY ESTA). 
Finally, the ESTAE routine decides to retry (RCVY ESTR).

The attached file has some extracts of the system trace. What puzzled me was 
the fact that I can see tons of IARV64 PAGEFIX entries after the "SVC D", 
followed by tons of "IARV64 PAGEOUT and IARV64 PAGEUNFIX" entries. And it takes 
0.08 seconds (!!) until the ESTAE routine gets control (RCVY ESTA). 

I then recognized the "SysTrace Snapshot" trace entry just before the long 
series of IARV64 entries starts.

The only question I have for the moment is: Are those IARV64 entries related to 
saving the system trace table frames for all processors as part of recovery 
processing to invoke the ESTAE? If so, I can ignore them since the are not part 
of the problem.
 

--
Peter Hunkeler


 Von:  An:  Betreff: System Trace - 
Snapshot Datum: 09.05.17, 15:05

  0001 021A 009FEA30 *RCVY  PROG940CA000 000A   
  021A 021A 10:59:52.781287376  4D  
  0001 021A 009FEA30  
SSRV   12D  816CD0AA  009FEA30 000C8000 FF3A  Status   NDETcb Reset 
  10:59:52.781299001  4D   
 0001 021A 009FEA30  SSRV   12D  816CD0C6  009FEA30 000B8000 
  Status   SDETcb Reset   10:59:52.781302817  4D
    0001 021A 009FEA30  DSP
_016D03C0   26E5617C 269F9740    021A 021A 
10:59:52.781304903 4D07853400 8000 0001 
021A 009FEA30 *SVC  D _016D03C2  269FA0D0 26E5617C 269F9740 
 10:59:52.781305526 4D
07853400 8000 0001 021A 009FEA30  SSRV78  870EB416  FF50 
00C8 009FC500  Getmain 10:59:52.781307343  4D   
021A 0001 021A 009FEA30  SSRV78 
 870EB46A  FF70 1310 7F489CF0  Getmain 
10:59:52.781315167  4D   
021A 0001 021A 009FEA30  EXT   CALL _01C052F0  1202 
     021A 021A 10:59:52.781322973  4D   
 07042000 8000   0001 021A 
009FEA30  DSP_01C052F0  0080 009FFCF0 7F48A1C0   
 021A 021A 10:59:52.781323845  4D
07042000 8000 0001 021A 009FEA30  SSRV78  816ADE36  E540 
0150 7F48EEB0  Getmain 10:59:52.781332365  4D   
021A 0001 021A 009FEA30  PC ... 
  0  016AE024  00506   SysTrace Snapshot 0001 021A 
009FEA30  SSRV78  A680645A  FF70 0338 7F7CECC8  Getmain 
10:59:52.781336086  4D  
 0004   … … 0001 021A 009FEA30  PR ...   0  26806BCC 
019E7418   0004 0001 021A 009FEA30  PC 
...   0  26806CD6  0090E   IarV64 0001 021A 009FEA30  
SSRV   14B  0401      IarV64   PageFix  
  10:59:52.782615394  4D   
_7F7CED98   
0050_0690   
_0100 0001 021A 009FEA30  EXT   CALL _019E7120  1202 
   0001 00FA4900 0004 0004 10:59:52.782615951 4D
07044001 8000   
0001 021A 009FEA30  DSP_019E7120  0080  00040300  
0001 00FA4900 0004 0004 10:59:52.782620331 4D   
 07044001 8000 … … 0001 021A 009FEA30  SSRV   14B  0601 
     IarV64   PageOut10:59:52.858250525  4D 
  _7F7CED98 
  0050_09D0 
  _0100 0001 021A 009FEA30  PR ...   0  
26807616 019E7418   0004 0001 021A 
009FEA30  PC ...   0  268075D2  0090E   IarV64 

Merging SYSPLEXes Information....

[Cameron Conacher]

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 SYSPLEX #7 data would
available to SYSPLEX #1, so it would be much easier to migrate workloads
from one LPAR to another.

When I use my old friend Google, I get lots of hits on creating a SYSPLEX,
but I wanted to be able to merge two SYSPLEXes into one.

Can someone point me to some information I could read through that would
help me get my arms around this one?

Thanks,

...Cameron

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

DFDSS QUESTION :SHARE PARM WHEN DOING COPY

[willie bunter]

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 exclusive; you cannot specify these keywords
together.
Do not specify DELETE if you specify SHARE. You must have exclusive control
over data sets that are to be deleted; SHARE does not require such exclusive
control.
Note: Unlike the RESTORE command, the COPY command honors the SHARE
keyword for VSAM data sets. However, the SHARE keyword is only honored for
VSAM data sets that were defined with share options other than (1,3) or (1,4).
Specifying the SHARE keyword does not cause DFSMSdss to honor the share
options that are defined for VSAM data sets. For VSAM data sets that are defined
with share options other than (1,3) or (1,4), specifying the SHARE keyword 
allows
other programs to obtain read access. It does not, however, allow write access 
to
the data sets while they are being copied. For VSAM data sets that are defined
with share options (1,3) or (1,4), neither read access nor write access by other
programs is allowed while the data set is being copied.

If my understanding is correct the SHARE parm applis to VSAM dsns which are 
defined with share options (2,3) .  However the dsn in question is that it is 
an OAM file.  Would the SHARE apply to OAM dsns as well?
Before the COPY is executed the file is closed on CICS.  However after the COPY 
step has executed of the dsn (no warnings or errors received)  the job abends 
at the following step which tries to enable the file on CICS because the dsn is 
not released from the job until it completes.  The job has 6 steps.  
My question is shouldn''t the dsn be released after the COPY step is has 
completed or does dsn is released at the end ot the job?  Could someone please 
clear this up for me?

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

Re: AW: Re: job output into dataset

[venkat kulkarni]

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

and also after spin, all these messages should be no longer exist in this
imsproc.



  SDSF JOB DATA SET DISPLAY - JOB IMS12IMS (STC01559)LINE 1-5
(5)

 COMMAND INPUT ===>SCROLL ===>
CSR

 PREFIX=DBC*  DEST=(ALL)  OWNER=*  SYSNAME=


 NP   DDNAME   StepName ProcStep DSID OwnerC Dest   Rec-Cnt
Page

  JESMSGLG JES2 2 STCCICT  Z
5

  JESJCL   JES2 3 STCCICT  Z
229

  JESYSMSG JES2 4 STCCICT  Z
3

  JESMSGLG JES2   103 STCCICT  Z
869

  JESYSMSG JES2   104 STCCICT  Z
0



To make this process work, do I need to code DD statement in IMS proc like
below



//JESMSGLG DD SYSOUT=A,FREE=CLOSE,SPIN=UNALLOC



before running spin command  ex : $T IMS12IMS,SPIN,DD=JESMSGLG



or there is no need to code this  //JESMSGLG DD
SYSOUT=A,FREE=CLOSE,SPIN=UNALLOC
DD statement inside IMS proc.



I am asking this query because, currently in my IMS proc, I have only below
DD statement



//STEPLIB  DD DSN=IMS1.V120.,DISP=SHR

//PROCLIB  DD DSN=IMS1.V120.,DISP=SHR

//DFSOLP00 DD DSN=IMS1.V120.,DISP=SHR

//DFSOLP01 DD DSN=IMS1.V120.,DISP=SHR

//DFSOLP99 DD DSN=IMS1.V120.,DISP=SHR

//DFSWADS0 DD DSN=IMS1.V120.,DISP=SHR

//DFSWADS1 DD DSN=IMS1.V120.,DISP=SHR

//IMSACBA  DD DSN=IMS1.V120.ACBLIBA,DISP=SHR

//IMSACBB  DD DSN=IMS1.V120.ACBLIBB,DISP=SHR

//MODBLKSA DD DSN=IMS1.V120.,DISP=SHR

//MODBLKSB DD DSN=IMS1.V120.,DISP=SHR

//MODSTAT  DD DSN=IMS1.V120.,DISP=SHR

//SYSUDUMP DD SYSOUT=,

//IMSRDS   DD DSN=IMS1.V120.,DISP=SHR

//MATRIXA  DD DSN=IMS1.V120.,DISP=SHR

//MATRIXB  DD DSN=IMS1.V120.,DISP=SHR

//PRINTDD  DD SYSOUT=

//IMSMON   DD DSN=IMS1.V120.IMSMON,DISP=SHR

//DFSESL   DD DSN=IMS1.V120.,DISP=SHR



and when I run $T IMS12IMS,SPIN,DD=JESMSGLG command, I see all record line
comes to zero in address space or JESMSGLG DD but system create one more DD
with same name JESMSGLG,

but I am not sure how this happens ??



And SPIN command output never complete and i just get below message but
never received message saying " SPIN successfully completed."



$T IMS12IMS,SPIN,DD=JESMSGLG



$HASP890 JOB(DBCY2RC3) 878

$HASP890 JOB(DBCY2RC3)  STATUS=(EXECUTING/TST4),CLASS=STC,

$HASP890PRIORITY=15,SYSAFF=(TST4),HOLD=(NONE)





Now, my another query is , when I run this SPIN command and my DD JESMSGLG
record comes to zero then where all these message gone. Are they purged or
I can view them.



I tried looking at output but I don’t find any print named IMS12IMS .



Can you please guide me with this whole process



On 09-May-2017 10:42 AM, "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.
>
> Please correct me, if my understanding is wrong.
> Also, suggest after this spin , how to remove those many record from JESMSGLG
> dd which we just spin .
>
> On 09-May-2017 9:40 AM, "Gibney, Dave"  wrote:
>
>> 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: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: Re: AW: Re: job output into dataset
>> >
>> > Hello All,
>> >
>> >
>> >
>> > Thanks for reply. I looked at my IMS proc and looks like below.
>> >
>> >
>> >
>> > BROWSESYS1.DEVL.PROCLIB(IMS12IMS) - 01.05Line  Col
>> 001
>> > 080
>> >
>> >  Command ===>  Scroll
>> ===>
>> > CSR
>> >
>> > * Top of Data
>> > **
>> > 
>> >
>> > //   PROC RGN=0M,SOUT=A,
>> >
>> > //SYS=,SYS2=,
>> >
>> > //RGSUF=DBC,PARM1='AUTO=N',
>> >
>> > //PARM2=
>> >
>> > //IEFPROC EXEC PGM=DFSMVRC0,REGION=,
>> >
>> > //PARM='DBC,,,'
>> >
>> > //*
>> >
>> > //STEPLIB  DD DSN=IMS1.V120.,DISP=SHR
>> >
>> > //PROCLIB  DD DSN=IMS1.V120.,DISP=SHR
>> >
>> > //*
>> >
>> > //IMSIRD   DD SYSOUT=(A,INTRDR)
>> >
>> > //*
>> >
>> > //*
>> >
>> > //DFSOLP00 DD DSN=IMS1.V120.,DISP=SHR
>> >
>> > //DFSOLP01 DD DSN=IMS1.V120.,DISP=SHR
>> >
>> > //DFSOLP99 DD DSN=IMS1.V120.,DISP=SHR
>> >
>> > //*
>> >
>> > //DFSWADS0 DD DSN=IMS1.V120.,DISP=SHR
>> >
>> > //DFSWADS1 DD DSN=IMS1.V120.,DISP=SHR
>> >
>> > //*
>> >
>> > //IMSACBA  DD DSN=IMS1.V120.ACBLIBA,DISP=SHR
>> >

Re: AW: Re: job output into dataset

[venkat kulkarni]

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 to remove those many record from JESMSGLG
dd which we just spin .

On 09-May-2017 9:40 AM, "Gibney, Dave"  wrote:

> 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: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: AW: Re: job output into dataset
> >
> > Hello All,
> >
> >
> >
> > Thanks for reply. I looked at my IMS proc and looks like below.
> >
> >
> >
> > BROWSESYS1.DEVL.PROCLIB(IMS12IMS) - 01.05Line  Col
> 001
> > 080
> >
> >  Command ===>  Scroll
> ===>
> > CSR
> >
> > * Top of Data
> > **
> > 
> >
> > //   PROC RGN=0M,SOUT=A,
> >
> > //SYS=,SYS2=,
> >
> > //RGSUF=DBC,PARM1='AUTO=N',
> >
> > //PARM2=
> >
> > //IEFPROC EXEC PGM=DFSMVRC0,REGION=,
> >
> > //PARM='DBC,,,'
> >
> > //*
> >
> > //STEPLIB  DD DSN=IMS1.V120.,DISP=SHR
> >
> > //PROCLIB  DD DSN=IMS1.V120.,DISP=SHR
> >
> > //*
> >
> > //IMSIRD   DD SYSOUT=(A,INTRDR)
> >
> > //*
> >
> > //*
> >
> > //DFSOLP00 DD DSN=IMS1.V120.,DISP=SHR
> >
> > //DFSOLP01 DD DSN=IMS1.V120.,DISP=SHR
> >
> > //DFSOLP99 DD DSN=IMS1.V120.,DISP=SHR
> >
> > //*
> >
> > //DFSWADS0 DD DSN=IMS1.V120.,DISP=SHR
> >
> > //DFSWADS1 DD DSN=IMS1.V120.,DISP=SHR
> >
> > //*
> >
> > //IMSACBA  DD DSN=IMS1.V120.ACBLIBA,DISP=SHR
> >
> > //*DD DSN=DBCR.V120.ACBLIB.FAID,DISP=SHR
> >
> > //IMSACBB  DD DSN=IMS1.V120.ACBLIBB,DISP=SHR
> >
> > //*DD DSN=DBCR.V120.ACBLIB.FAID,DISP=SHR
> >
> > //MODBLKSA DD DSN=IMS1.V120.,DISP=SHR
> >
> > //MODBLKSB DD DSN=IMS1.V120.,DISP=SHR
> >
> > //MODSTAT  DD DSN=IMS1.V120.,DISP=SHR
> >
> > // SYSTEM REQUIRED DD CARDS **
> >
> > //*
> >
> > //SYSUDUMP DD SYSOUT=,
> >
> > // DCB=(LRECL=125,RECFM=FBA,BLKSIZE=3129),
> >
> > // SPACE=(6050,300,,,ROUND)
> >
> > //IMSRDS   DD DSN=IMS1.V120.,DISP=SHR
> >
> > //MATRIXA  DD DSN=IMS1.V120.,DISP=SHR
> >
> > //MATRIXB  DD DSN=IMS1.V120.,DISP=SHR
> >
> > //PRINTDD  DD SYSOUT=
> >
> > //*
> >
> > //IMSMON   DD DSN=IMS1.V120.IMSMON,DISP=SHR
> >
> >
> > //** EXTERNAL SUBSYSTEM DD CARDS  ***
> >
> > //*
> >
> > //* USER MAY OPTIONALLY ADD THE DFSESL DD CARD
> >
> > //* FOR EXTERNAL SUBSYSTEM CONNECTION.
> >
> > //*
> >
> > //DFSESL   DD DSN=IMS1.V120.,DISP=SHR
> >
> > // DATA BASE DD CARDS ***
> >
> >  Bottom of Data
> > 
> >
> >
> >
> > And in DA, I see this
> >
> >
> >
> > COMMAND INPUT ===>
> >
> > PREFIX=IMS12IMS  DEST=(ALL)  OWNER=*  SYSNAME=
> >
> > NP   DDNAME   StepName ProcStep DSID OwnerC Dest
> >
> >  JESMSGLG JES2 2STCBRCR  Z
> >
> >  JESJCL   JES2 3 STCBRCR  Z
> >
> >  JESYSMSG JES2 4STCBRCR  Z
> >
> >  JESMSGLG JES2   104STCBRCR  Z
> >
> >  JESYSMSG JES2   105STCBRCR  Z
> >
> >
> >
> > So, I don’t have any other SYSOUT withSYSOUT=*   or SYSOUT=A as you can
> > see
> > in the above mentioned proc.
> >
> >
> >
> > So, can you please suggest, what are all change I need to make for spin
> to
> > work .
> >
> > I think, I will also have to addFREE=CLOSE,SPIN=UNALLOC in this IMS proc
> DD,
> > So that spin function can work. Because, currently when I run spin
> command
> > like below,
> >
> > $T JQ(IMS12RC3),SPIN,DDNAME=JCLOUT
> >
> >
> >
> > I just get output as below.
> >
> >
> >
> > and output from this command is
> >
> > RESPONSE=TST4
> >
> > $HASP890 JOB(IMS12RC3)
> >
> >  $HASP890 JOB(IMS12RC3)  STATUS=(EXECUTING/TST4),CLASS=STC,
> >
> >  $HASP890PRIORITY=15,SYSAFF=(TST4),HOLD=(NONE)
> >
> >
> >
> > But this doesn’t show that spin successfully completed or not.
> >
> >
> >
> > I tried to provide you as much as detail this time. Can you please
> suggest,
> > how spin will work looking at my current proc
> >
> >
> >
> > On 08-May-2017 6:14 PM, "Barkow, Eileen"  wrote:
> >
> > > As I explained to Vekat, he can use the  SDSF/REXX clist I  gave him
> > > to extract and archive the SYSOUT queue to a dataset as allocated in
> the
> > clist.
> > > Then the clist can issue a command like:
> > >
> > > $TSTC04306,SPIN,DDNAME=DDNTOSPIN
> > > To drain the queue.
> > >
> > > The clist has the started task number to use for the $Tstcno,SPIN
> > command.
> > > Code can also be added to 

Re: AW: Re: job output into dataset

[Gibney, Dave]

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: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AW: Re: job output into dataset
> 
> Hello All,
> 
> 
> 
> Thanks for reply. I looked at my IMS proc and looks like below.
> 
> 
> 
> BROWSESYS1.DEVL.PROCLIB(IMS12IMS) - 01.05Line  Col 001
> 080
> 
>  Command ===>  Scroll ===>
> CSR
> 
> * Top of Data
> **
> 
> 
> //   PROC RGN=0M,SOUT=A,
> 
> //SYS=,SYS2=,
> 
> //RGSUF=DBC,PARM1='AUTO=N',
> 
> //PARM2=
> 
> //IEFPROC EXEC PGM=DFSMVRC0,REGION=,
> 
> //PARM='DBC,,,'
> 
> //*
> 
> //STEPLIB  DD DSN=IMS1.V120.,DISP=SHR
> 
> //PROCLIB  DD DSN=IMS1.V120.,DISP=SHR
> 
> //*
> 
> //IMSIRD   DD SYSOUT=(A,INTRDR)
> 
> //*
> 
> //*
> 
> //DFSOLP00 DD DSN=IMS1.V120.,DISP=SHR
> 
> //DFSOLP01 DD DSN=IMS1.V120.,DISP=SHR
> 
> //DFSOLP99 DD DSN=IMS1.V120.,DISP=SHR
> 
> //*
> 
> //DFSWADS0 DD DSN=IMS1.V120.,DISP=SHR
> 
> //DFSWADS1 DD DSN=IMS1.V120.,DISP=SHR
> 
> //*
> 
> //IMSACBA  DD DSN=IMS1.V120.ACBLIBA,DISP=SHR
> 
> //*DD DSN=DBCR.V120.ACBLIB.FAID,DISP=SHR
> 
> //IMSACBB  DD DSN=IMS1.V120.ACBLIBB,DISP=SHR
> 
> //*DD DSN=DBCR.V120.ACBLIB.FAID,DISP=SHR
> 
> //MODBLKSA DD DSN=IMS1.V120.,DISP=SHR
> 
> //MODBLKSB DD DSN=IMS1.V120.,DISP=SHR
> 
> //MODSTAT  DD DSN=IMS1.V120.,DISP=SHR
> 
> // SYSTEM REQUIRED DD CARDS **
> 
> //*
> 
> //SYSUDUMP DD SYSOUT=,
> 
> // DCB=(LRECL=125,RECFM=FBA,BLKSIZE=3129),
> 
> // SPACE=(6050,300,,,ROUND)
> 
> //IMSRDS   DD DSN=IMS1.V120.,DISP=SHR
> 
> //MATRIXA  DD DSN=IMS1.V120.,DISP=SHR
> 
> //MATRIXB  DD DSN=IMS1.V120.,DISP=SHR
> 
> //PRINTDD  DD SYSOUT=
> 
> //*
> 
> //IMSMON   DD DSN=IMS1.V120.IMSMON,DISP=SHR
> 
> 
> //** EXTERNAL SUBSYSTEM DD CARDS  ***
> 
> //*
> 
> //* USER MAY OPTIONALLY ADD THE DFSESL DD CARD
> 
> //* FOR EXTERNAL SUBSYSTEM CONNECTION.
> 
> //*
> 
> //DFSESL   DD DSN=IMS1.V120.,DISP=SHR
> 
> // DATA BASE DD CARDS ***
> 
>  Bottom of Data
> 
> 
> 
> 
> And in DA, I see this
> 
> 
> 
> COMMAND INPUT ===>
> 
> PREFIX=IMS12IMS  DEST=(ALL)  OWNER=*  SYSNAME=
> 
> NP   DDNAME   StepName ProcStep DSID OwnerC Dest
> 
>  JESMSGLG JES2 2STCBRCR  Z
> 
>  JESJCL   JES2 3 STCBRCR  Z
> 
>  JESYSMSG JES2 4STCBRCR  Z
> 
>  JESMSGLG JES2   104STCBRCR  Z
> 
>  JESYSMSG JES2   105STCBRCR  Z
> 
> 
> 
> So, I don’t have any other SYSOUT withSYSOUT=*   or SYSOUT=A as you can
> see
> in the above mentioned proc.
> 
> 
> 
> So, can you please suggest, what are all change I need to make for spin to
> work .
> 
> I think, I will also have to addFREE=CLOSE,SPIN=UNALLOC in this IMS proc DD,
> So that spin function can work. Because, currently when I run spin command
> like below,
> 
> $T JQ(IMS12RC3),SPIN,DDNAME=JCLOUT
> 
> 
> 
> I just get output as below.
> 
> 
> 
> and output from this command is
> 
> RESPONSE=TST4
> 
> $HASP890 JOB(IMS12RC3)
> 
>  $HASP890 JOB(IMS12RC3)  STATUS=(EXECUTING/TST4),CLASS=STC,
> 
>  $HASP890PRIORITY=15,SYSAFF=(TST4),HOLD=(NONE)
> 
> 
> 
> But this doesn’t show that spin successfully completed or not.
> 
> 
> 
> I tried to provide you as much as detail this time. Can you please suggest,
> how spin will work looking at my current proc
> 
> 
> 
> On 08-May-2017 6:14 PM, "Barkow, Eileen"  wrote:
> 
> > As I explained to Vekat, he can use the  SDSF/REXX clist I  gave him
> > to extract and archive the SYSOUT queue to a dataset as allocated in the
> clist.
> > Then the clist can issue a command like:
> >
> > $TSTC04306,SPIN,DDNAME=DDNTOSPIN
> > To drain the queue.
> >
> > The clist has the started task number to use for the $Tstcno,SPIN
> command.
> > Code can also be added to extract the number of existing lines in the
> > DDNAME to determine whether or not to spin it.
> > Any DDNAME can be specified.
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On Behalf Of venkat kulkarni
> > Sent: Monday, May 08, 2017 3:34 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: AW: Re: job output into dataset
> >
> > Just to add one more thing . Under ims12rc3 address space , below are
> > dd name available.
> >
> > COMMAND INPUT ===>
> >
> > PREFIX=*  DEST=(ALL)  OWNER=*
> >
> > NP   DDNAME   StepName ProcSte
> >
> >  JESMSGLG JES2
> >
> >  JESJCL   JES2
> >
> >  JESYSMSG JES2
> >
> >  JESMSGLG JES2
> >
> >  JESYSMSG JES2
> >
> > On