Re: Capturing STC SYSOUT when the STC is shut down

[saul anthony babonas]

The requirement to keep and archive SYSOUT can be done as 
follows

//SYSOUT DD 
DSN=YOUR.SYSPRINT.GDG.DATASET(+1),DISP=(NEW,CATLG,DELETE),etc,etc

The additional requirement to view while the STC is up and running.
..sorry but retirement has impacted by memory of gadgetry but 
there's a simple method to write SYSOUT to 2 DD cards, the 2nd of
which will be SDSF viewable. Someone younger I hope can chime in.




On 8/16/2016 10:09 AM, Nims,Alva John (Al) wrote:
> I think there are at least two options:
> 1. Since you have already mentioned SDSF, yes I believe you can use SDSF to 
> copy the output and write it to a GDG, I have done it in the past, but 
> unfortunately all that code of mine is gone and I no longer have access to 
> SDSF to help you further.
> 2. This is also an option in that is readily available as part of z/OS and 
> does not require installing any additional software; it does use a UNIQUE 
> output class (it helps, but is not completely required) that you can start a 
> JES2 external writer to read the SYSOUT and write to a GDG, you might have to 
> submit a JOB or start a "Started Task" before leaving the original JOB to do 
> that, because the SYSOUT must be closed and freed before the external writer 
> can read the output.
>
> There is a 3rd option, but ONLY IF you have $AVERS (Software Engineering of 
> America (SEA)) I think it has options to do this where you do not need a 
> unique output class and can be done by JOBName, I think, so don't quote me on 
> that and if you do not already have $AVERS installed, it is a moot point, 
> unless you are ready to spend money.
>
> Al Nims
> Systems Admin/Programmer 3
> UFIT
> University of Florida
> (352) 273-1298
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jon Bathmaker
> Sent: Tuesday, August 16, 2016 10:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Capturing STC SYSOUT when the STC is shut down
>
> Hi,
> We are running NVAS and the SYSPRINT file gets directed to SYSOUT=* which is 
> fine as we can browse it if we need to.
>
> For some reason (Audit request?) I am being asked to vacuum up the SYSOUT 
> file and put it into a GDG when the task is recycled, while still leaving it 
> as SYSOUT when the STC is active. .   Based on a message I received, a disp 
> of PASS and SYSOUT are incompatible.   I am now considering using SDSF in 
> batch so solve this problem (thanks to Lorne Heffer).
>
> Anyone have any ideas?   Using a commercial Program Product is a non-starter 
> as, like everyone else the client is only interested in lower cost.   Thanks.
>
> Regards,
> Jon Bathmaker
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: Blue Screen Of Death, mainframe-style

[saul anthony babonas]

True. The effect of DVCDN is reversed by DVCUP.



Sent via the Samsung Galaxy Note® 4, an AT 4G LTE smartphone


 Original message 
From: Charles Mills 
Date: 8/1/2016 7:55 AM (GMT-06:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Blue Screen Of Death, mainframe-style

My recollection of DVCDN is that it would not have affected anything that
would span an IPL. In other words, a vanilla re-IPL would have solved any
"damage" done by DVCDN. If this story is not a myth then at least it is
missing some key detail.

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gerhard Adam
Sent: Saturday, July 30, 2016 2:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Blue Screen Of Death, mainframe-style

> He tries to restart the big machine, but that fails almost immediately.
Turns out that the second command in the startup sequence is one that
directs output to the printer known as 00E -- which the mainframe no longer
knows how to use.

What does that sentence even mean?   Any printer at any address would've
been "known" much later in the IPL process and there was nothing "known" at
the actual point of IPL.

Again, the story sounds like a fairy tale.

--
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: Datasets usage question

[saul anthony babonas]

Not that this will remedy your current situation, but.

for future reference it might be advisable to create a member in the JCL 
library(ies) that establishes the dataset names via SET commands. You 
could then INCLUDE this member in various JCL members. When it's time to 
upgrade the dataset names are all in one (or very few) places.



On 6/23/2016 4:27 PM, Edward Gould wrote:
> Yikes, I would *NEVER* consider using alias’s.
> Two things come to mind there is on CBTTAPE.ORG a find replace editor (or use 
> the one that IBM use to give out on the CBPDO, that even might be on CBTAPE 
> its been a while since I went through it.
> The smart way is to use DAF (on CBTTAPE  and find who is referencing them and 
> you can track (mostly) easily who is using them and to tell them to change it.
> Alias’s will have to be maintained *FOREVER* and no one wants to do that. 
> Mastercats should be reasonably stable. If you must create a new master cat 
> there are some freebie utilities (on CBTTAPE) to read and create the control 
> cards for the new master cat.
> IMO alias’s are an evil thing that gets out of hand real quickly and become 
> crutch’s.
>
> Ed
>
>> On Jun 23, 2016, at 3:33 PM, retired mainframer  
>> wrote:
>>
>> You could consider using dataset aliases.  It might eliminate the need for 
>> any JCL changes.
>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>>> Behalf Of Duc
>>> Sent: Thursday, June 23, 2016 8:22 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Datasets usage question
>>>
>>> Dear listers,
>>>
>>> We are changing our DB2 library  datasets naming convention, and i would 
>>> like to list all
>>> datasets usage  (essentially *.SDSNLOAD, but ther can be some others)  to 
>>> be able to
>>> change the jcls and others accordingly.
>>> I know that i can use SMF 14 records to realise this
>>>
>>> Do you have any other advice in order allow the change to be as invisible 
>>> as possible ?
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: AW: Re: TIOT exceeded

[saul anthony babonas]

Years ago we had an application that needed to sequentially read all 
generations of a GDG for reason that I've long forgotten. The "read" 
program would do its process, then delete the input file. The next step 
would submit itself back to the internal reader. Once the job was 
submitted we could go drink coffee till all generations were read and 
deleted. Once exhausted the last job would fail due to JCL error.


if you're not in a hurry...the price is right.


On 6/23/2016 7:44 AM, Tom Marchant wrote:
> On Thu, 23 Jun 2016 11:12:10 +0530, Jake Anderson wrote:
>
>> I am little worried as the GDG limits after zOS 2.2 going to be more than
>> 255. So not sure if TIOT limit of 64k is going to help ?
> IIRC you are running a single IEFBR14 step to delete all of the multi-volume
> generation data sets for multiple generation data groups. Since you are 
> running
> into TIOT limits, you need to do something different.
>
> Increasing the size of the TIOT from 48K to 64K will give you some relief, 
> perhaps
> enough for now, perhaps not for the future.
>
> You could run more than one IEFBR14 step, one for each GDG.
>
> You could do it another way, for example with IDCAMS.
>


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

Re: Where is format of Job ID documented?

[saul anthony babonas]

Years ago when my then employer started using the OMVS technology the ESM was 
CA TOP SECRET. Processes failed because the inherited user did not have access 
to the STC "facility". TS allows you to control the ability to initiate a 
started task. Upon some head scratching analysis "holy cow, this stuff coming 
from the dark side uses mini STCS to do their thing."
So we had to allow any user who did OMVS processes the ability to initiate a 
started task.
I have long since forgotten which processes (oh, like I ever knew) become 
started tasks. We figured all of them but never tested in order to be positive.
Wish I would have learned better.



Sent via the Samsung Galaxy Note® 4, an AT 4G LTE smartphone


 Original message 
From: Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Date: 6/17/2016 6:25 AM (GMT-08:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is format of Job ID documented?

On Thu, 16 Jun 2016 22:03:36 -0400, Robert A. Rosenberg wrote:

>At 15:43 -0700 on 06/16/2016, Charles Mills wrote about Re: Where is
>format of Job ID documented?:
>
>>Thanks. Anyone ever see an 'O'? Or a Mount?
>
>I think Mount is a Started Task and thus is S. OTOH: It might run
>under Master Scheduler not JES.

IIRC, there three ways in MVS to create an address space: Start, Logon and 
Mount.

So, is mount a started task? I don't know, but my guess is "no".

Job ID is a JES construct, and I wouldn't expect JES to be involved in Mount.

IIRC, JES3 assigns Job ID differently from JES2.

--
Tom Marchant

--
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: IEBPTPCH (was: Read a PDS ...)

[saul anthony babonas]

Caution: From a retiree out of the game for 12 months
//job etc etc
//exec pgm=ikjeft01
//systsprt DD dsn=your.output,disp=(new),dcb=lrecl=I don't remember
//systsin DD *
 Printds hlq.your.PDS.   or pdse



Sent via the Samsung Galaxy Note® 4, an AT 4G LTE smartphone


 Original message 
From: "Staller, Allan" <allan.stal...@wunderman.com>
Date: 6/17/2016 5:42 AM (GMT-08:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

Would you be willing to share?


From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of saul anthony babonas
Sent: Thursday, June 16, 2016 11:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

I've been following this discussion with some belated interest. Years ago I 
cooked up something dirt simple to turn a PDS into a SD file using the TSO 
print command. It wasn't very elegant but it got the job done at low cost.


This email ? including attachments ? may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

--
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: IEBPTPCH (was: Read a PDS ...)

[saul anthony babonas]

Sequential disk



Sent via the Samsung Galaxy Note® 4, an AT 4G LTE smartphone


 Original message 
From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Date: 6/16/2016 9:54 PM (GMT-08:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

On Fri, 17 Jun 2016 04:26:41 +, saul anthony babonas wrote:

>I've been following this discussion with some belated interest. Years ago I 
>cooked up something dirt simple to turn a PDS into a SD file using the TSO 
>print command. It wasn't very elegant but it got the job done at low cost.
>
SD?  Like a USB flash card?

> Original message 
>From: Edward Gould
>Date: 6/16/2016 9:19 PM (GMT-08:00)
>
>There are many peculiarities with IEBPTPCH. Like it doesn�t output in member 
>sequence (I vaguely remember that it is TTR sequence (but could be wrong).
>
Indeed.  While testing, I created a member, AAA* so it would be first.  It
appeared last.  Optimize seek movement.  First read the directory.  Sort
in TTR order.  FIND each member.  Great idea if you're the only job
using the device.

>The control card format is anything but intuitive I am iffy here but IIRC you 
>must specify maxflds (why I have no clue) I hated the damn program myself as I 
>had to relearn the control cards  all the time.
>
IEBGENER has something similar.  I guessed it's to know how much working
storage to GETMAIN.  I just used a big number and suitable REGION.

It should have stayed in the 20th Century.  Today, I think I'd NFS mount my
PDS on Solaris and use "pax".

But IEBGENER will create aliases.  I don't think it would work to NFS mount
on Solaris and use "ln".

-- gil

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

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

Re: IEBPTPCH (was: Read a PDS ...)

[saul anthony babonas]

I've been following this discussion with some belated interest. Years ago I 
cooked up something dirt simple to turn a PDS into a SD file using the TSO 
print command. It wasn't very elegant but it got the job done at low cost.



Sent via the Samsung Galaxy Note® 4, an AT 4G LTE smartphone


 Original message 
From: Edward Gould 
Date: 6/16/2016 9:19 PM (GMT-08:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

Paul:

There are many peculiarities with IEBPTPCH. Like it doesn’t output in member 
sequence (I vaguely remember that it is TTR sequence (but could be wrong).
The control card format is anything but intuitive I am iffy here but IIRC you 
must specify maxflds (why I have no clue) I hated the damn program myself as I 
had to relearn the control cards  all the time.
IEHMOVE was another PITA. The only reason to use IEHMOVE (Memory is shady here 
people) is that it allocated the output file for you.
Ed
> On Jun 14, 2016, at 7:59 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Tue, 14 Jun 2016 18:03:02 -0500, wrote:
>
>> I'm not sure why you'd think it may have problems punching/printing PDS 
>> members that happen to contain JCL which happens to contain IEBPTPCH 
>> commands. It's all just data to IEBPTPCH.
>>
> OK.  I tried it.  Members appear to be separated by lines of the form "MEMBER 
> NAME  ".
> (Is this documented?)  What happens if such a line appears in SYSUT1?  I got:
>
> MEMBER NAME  AAAWTF control line
>  Line before   data line
> MEMBER NAME  FOOBAR data line (but how does it know?)
>  Line afterdata line
>
>> It is documented, you could consider giving it a whirl with something else 
>> and lettings us know.
>>
> Wherein I find gems such as:
>
>Both the output data set and the message data set can be written to the
>system output device if it is a printer.
>
> What does that mean?  If it's not a printer, can only one of them be written 
> to it?
>
>If the member card entry is not used, the entire data cell will be printed.
>
> How long has it been since IBM marketed a data cell?  (I'll submit an RCF on 
> that.)
>
> How does one restore a PDS from IEBPTPCH output?  It's probably somewhere.
> I haven't found it.
>
> (Is this good old IBM documentation or sloppy new IBM documentation?)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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