Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[David Purdy]

Or his cousin Wylbur?



On Thursday, June 29, 2017 J R  wrote:
No. I've heard of ROSCOE but I've never encountered it. 

> 

On Jun 29, 2017, at 20:31, Anthony Thompson  wrote:
> 
> Is it possible that it is ROSCOE (alternative to TSO) that your lonely last 
> brain cell is trying to remember?

--
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: Using RACROUT and Facility Class

[Rugen, Len]

It's been several years for me also, but this looks like a typical "user space" 
call, the doc here
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ichc600/auth.htm


calls this a "first-party" type.


Len Rugen

University of Missouri
Division of Information Technology
Systems & Operations - Metrics & Automation Team

From: IBM Mainframe Discussion List  on behalf of 
esst...@juno.com 
Sent: Thursday, June 29, 2017 7:53:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Using RACROUT and Facility Class

Hello
.
I am not a RACF Security Administrator by any means, after reading several 
documents
I need some help setting up a RACF Facility Class and Permitting Access To a
Started Task Userid (STCUSRID) and My Userid (PAULD01).

Do the following RACF Commands Define a Facility Class BLUE_RIBBON.SYS1.MSTRUPDT
and Have I permitted the Started Task Userid (STCUSRID) Update access to the 
Facility
and My Userid PAULD01 Read access ?
*
RDEFINE FACILITY BLUE_RIBBON.SYS1.MSTRUPDT UACC(NONE)
PERMIT  BLUE_RIBBON.SYS1.MSTRUPDT CLASS(FACILITY) ID(STCUSRID) ACCESS(UPDATE)
PERMIT  BLUE_RIBBON.SYS1.MSTRUPDT CLASS(FACILITY) ID(PAULD01) ACCESS(READ)
*
*
No for the code ...
*
*
FACILITY$ DC   CL8'FACILITY'
STEM  DC   H'00',H'00'
  DC   CL13'BLUE_RIBBON.SYS1.MSTRUPDT'
STEM#EQU   *-STEM
*
 DS0D
RACLAB   RACROUTE REQUEST=AUTH,ATTR=READ,CLASS='FACILITY',XX
   RELEASE=1.9,MF=L
 DS  XL8
RACLAB#  EQU  *-RACLAB

 MVC  SEC_ENTITY,STEM

 RACROUTE REQUEST=AUTH,   **
   WORKA=(R10),   **
   ATTR=READ, **
   ENTITYX=SEC_ENTITY,**
   CLASS=FACILITY$,   **
   MSGSUPP=NO,**
   LOG=ASIS,  **
   MF=(E,RACLAB)
*
*
Does the Above RACROUTE REQUEST=AUTH macro verify that the userid has
Read Authority to the Facility ?
Have I coded it properly ?
.
.
Without specifying a Userid, Is the ACEE used to verify the user ?
*
*
Should a Userid be explicitly specified on the command ?
*
*
Thank You
Paul D'Angelo
*

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

Using RACROUT and Facility Class

[esst...@juno.com]

Hello
.
I am not a RACF Security Administrator by any means, after reading several 
documents
I need some help setting up a RACF Facility Class and Permitting Access To a
Started Task Userid (STCUSRID) and My Userid (PAULD01).

Do the following RACF Commands Define a Facility Class BLUE_RIBBON.SYS1.MSTRUPDT
and Have I permitted the Started Task Userid (STCUSRID) Update access to the 
Facility
and My Userid PAULD01 Read access ?
*
RDEFINE FACILITY BLUE_RIBBON.SYS1.MSTRUPDT UACC(NONE)
PERMIT  BLUE_RIBBON.SYS1.MSTRUPDT CLASS(FACILITY) ID(STCUSRID) ACCESS(UPDATE)
PERMIT  BLUE_RIBBON.SYS1.MSTRUPDT CLASS(FACILITY) ID(PAULD01) ACCESS(READ)
*
*
No for the code ...
*
*
FACILITY$ DC   CL8'FACILITY'
STEM  DC   H'00',H'00' 
  DC   CL13'BLUE_RIBBON.SYS1.MSTRUPDT' 
STEM#EQU   *-STEM  
*  
 DS0D  
RACLAB   RACROUTE REQUEST=AUTH,ATTR=READ,CLASS='FACILITY',XX
   RELEASE=1.9,MF=L 
 DS  XL8   
RACLAB#  EQU  *-RACLAB 

 MVC  SEC_ENTITY,STEM

 RACROUTE REQUEST=AUTH,   **
   WORKA=(R10),   **
   ATTR=READ, **
   ENTITYX=SEC_ENTITY,**
   CLASS=FACILITY$,   **
   MSGSUPP=NO,**
   LOG=ASIS,  **
   MF=(E,RACLAB)  
*
*
Does the Above RACROUTE REQUEST=AUTH macro verify that the userid has
Read Authority to the Facility ?
Have I coded it properly ?
.
.
Without specifying a Userid, Is the ACEE used to verify the user ?
*
*
Should a Userid be explicitly specified on the command ?
*
*
Thank You
Paul D'Angelo
*

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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[J R]

No.  I've heard of ROSCOE but I've never encountered it. 

> On Jun 29, 2017, at 20:31, Anthony Thompson  
> wrote:
> 
> Is it possible that it is ROSCOE (alternative to TSO) that your lonely last 
> brain cell is trying to remember?

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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Anthony Thompson]

Is it possible that it is ROSCOE (alternative to TSO) that your lonely last 
brain cell is trying to remember?

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J R
Sent: Friday, 30 June 2017 7:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast 
for ever)

It really was a long time ago, but I think only one TSO user was swapped in at 
a time within each region.  (There were TSEVENTs then, much like SYSEVENTs 
now).  

Caveat:  I'm pretty much down to my last brain cell, so I could be 
misremembering.  I spent 50 years in this business;  the knowledge is still in 
my head but the table of contents and the index are both shot.  YMMV!  

> On Jun 29, 2017, at 16:09, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> What, then, was the scope of an allocation?  Of an ENQ?  What happened 
> if multiple users concurrently ALLOCATEd SYSUT2?  I suppose carefully 
> avoiding RET=HAVE could keep the DSN spaces separate.  And users would 
> just need to deal with that and the "IKJ56246I type_name NOT ALLOCATED, FILE 
> IN USE"
> condition.

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

Redbook DFHSM Primer

[Edward Gould]

IBM z/OS DFSMShsm Primer
Revised: June 21, 2017 ISBN: 0738440841 500 pages
Explore the book online at
http://www.redbooks.ibm.com/abstracts/sg245272.html?Open 

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

Re: IBM customer anchor

[Paul Gilmartin]

On Thu, 29 Jun 2017 23:02:22 +, scott Ford wrote:
>
>Are you saying we are better off, using our IBM assigned message prefix
>..which is MDI ...as part of our Token we use ?
> 
I believe he was more specific:
On Mon, 26 Jun 2017 08:28:06 -0400, Peter Relson wrote:
>... it has always been recommended that things like module and 
>macro names, message IDs, name/token names, dynamic exit names, and many 
>other things all begin with a prefix owned by the company that is using 
>the name/ID.

-- gil

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

Re: IBM customer anchor

[scott Ford]

Peter,

Are you saying we are better off, using our IBM assigned message prefix
..which is MDI ...as part of our Token we use ?

Scott

On Wed, Jun 28, 2017 at 7:47 AM Peter Relson  wrote:

> >Yes, I agree, we use IDENTI...
>
> I would say that that is wholly unacceptable unless you own the prefix
> IDE. If IBM creates a token that happens to collide then we may expect and
> require you to change. Is that likely? No. Is it conceivable? Yes. Some
> prefixes within the IBM range that had been appropriated by ISV's were
> grandfathered for use by the "offender". That was quite a long time ago
> now. I don't see that happening again since the process for an ISV to
> obtain a prefix has also existed for a long time now.
>
> A protocol is only as good as those who follow it. The naming protocol has
> served the platform well for 50-ish years. You should make an effort not
> to break it.
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Edward Gould]

> On Jun 29, 2017, at 2:23 PM, J R  wrote:
> 
> Well, it's a long, long time ago, but I seem to remember that many TSO 
> sessions would share a TSO Region, which was a single job. (No address spaces 
> then.).   If you had lots of TSO users, and sufficient horsepower, you would 
> run multiple TSO Regions. 

That is not how I remember it (multiple TSO regions) although I could be wrong. 
If memory serves me it was more or less important that you have enough storage 
as nothing was virtual back then. Of course horse power was an issue but 
storage was more important (at least on the systems I worked on).

Ed
> 
> On Jun 29, 2017, at 15:15, John McKown  > wrote:
> 
>>> More likely that all I/O was done in a TMP task that supported requests
>>> from the SEND and LISTBC commands.
>>> 
>> 
>> Console operator SEND? But, again, that was so long ago that I could easily
>> be having "critical ECC memory failure".
> 


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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Edward Gould]

> On Jun 29, 2017, at 12:07 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Thu, 29 Jun 2017 11:44:18 -0500, Elardus Engelbrecht wrote:
>> 
>> Or what are you using to determine that an id is 'inactive'?
>> 
> Are entries in SYS1.BRODCAST timestamped so they could be aged out?
> 
> What was the original design rationale for using a common SYS!.BRODCAST
> rather than individual ?  Allocation/OPEN/CLOSE
> overhead?  ENQ contention?  Space/VTOC constraint?  Other?
I can’t give a definitive answer but I can make a good guess on the common 
Broadcast. The original developers I am guessing did not want potentially 
1000’s of tiny datasets laying around. They opted for 1 dataset.
Broadcast was in (still in) mstrjcl so there was no need to do multiple 
opens/closes. As for contention it wasn’t all that bad as *I THINK* it was only 
enqued at update time. It was/is a BDAM dataset. 

Ed
> 
> UNIX facilities could be your friend here, even as UNIX batch jobs simply
> append their logs to the user's mbox.
> 
> -- 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: Choosing Windows for your organization should get you fired [Network World]

[Edward Gould]

> On Jun 29, 2017, at 6:43 AM, Mark Regan  wrote:
> 
> From Network World, Choosing Windows for your organization should get you
> fired
> 
> http://www.networkworld.com/article/3204156/windows-server/choosing-windows-for-your-organization-should-get-you-fired.html
>  
> 


Great one! I will forward it to my friends who are stuck in windows land, 
Thanks!

Ed
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,


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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[J R]

> On Jun 29, 2017, at 17:52, J R  wrote:
> 
> It really was a long time ago, but I think only one TSO user was swapped in 
> at a time within each region.  (There were TSEVENTs then, much like SYSEVENTs 
> now).  
> 
> Caveat:  I'm pretty much down to my last brain cell, so I could be 
> misremembering.  I spent 50 years in this business;  the knowledge is still 
> in my head but the table of contents and the index are both shot.  YMMV!  

So, to answer your question, DDnames, TIOTs, etc., LSQA, would be swapped out, 
therefore no collisions.  However, ENQs would remain in force globally. 


>> On Jun 29, 2017, at 16:09, Paul Gilmartin 
>> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> What, then, was the scope of an allocation?  Of an ENQ?  What happened if
>> multiple users concurrently ALLOCATEd SYSUT2?  I suppose carefully avoiding
>> RET=HAVE could keep the DSN spaces separate.  And users would just need to
>> deal with that and the "IKJ56246I type_name NOT ALLOCATED, FILE IN USE"
>> condition.
> 
> --
> 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: DFSORT to deal with IMS Date/Time

[Sri h Kolusu]

Dirceu Bimonti Ivo,

I sent you the JCL which meets your requirements along with time 
arithmetic and handle dates to subtract a day if the time - offset results 
in a negative number. 

Please let me know if you have any more questions.


Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on 
06/29/2017 10:45:52 AM:

> From: Dirceu Bimonti Ivo 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/29/2017 10:46 AM
> Subject: DFSORT to deal with IMS Date/Time
> Sent by: IBM Mainframe Discussion List 
> 
> Hi,
> 
> Could use some inputs from DFSORT experts. I have this job to sort 
> IMS Log Records using an specific criteria, does what it should, I 
> just can't get the date/time to display correctly. This is an 
> example of what it looks like:
> 
> +++++++++++-+-+
> | +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +10 | +11 |
> +++++++++++-+-+
> | YY | YY | DD | DF | HH | MM | SS | TH | MI | JU | A Q | Q $ |
> +++++++++++-+-+
> 
> 2017170F  13361016 8394020D
> 
> Translates to 2017.170 13:36:10.168394 UTC -5. Part I am failing is 
> the QQ$, which is the offset from UTC in quarter of hour, so x'20D' 
> means 20 quarter of hour, negative, or -5 hours. I should be 
> subtracting this from the HH field, using something like this:
> 
> OUTREC FIELDS=(1,4,   * RDW 
>89,1,PD,SUB,   * Hour 
>(95,2,PD,DIV,+4),  * UTC Offset 
>C' ')  * End of Record
> 
> It does not work because the offset 89 (HH) is not PD, so one digit 
> gets converted to the sign digit instead and the math will be off. 
> While looking for a solution to this, I realized that even if it 
> worked, suppose the record had HH=01 and UTC=-4, I would get a 
> negative time instead of wrapping back to 09 PM.
> 
> So, question finally, any way to maybe convert this to a SMF or TOD 
> format and properly parse using one of the DATE functions from 
> DFSORT instead ? Could probably do this writing a program, it is 
> just easier to quickly change the sort parameters or what you want 
> printed in the report using DFSORT than actually changing your program.
> 
> Thanks in advance.
> 
> --
> 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: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[J R]

It really was a long time ago, but I think only one TSO user was swapped in at 
a time within each region.  (There were TSEVENTs then, much like SYSEVENTs 
now).  

Caveat:  I'm pretty much down to my last brain cell, so I could be 
misremembering.  I spent 50 years in this business;  the knowledge is still in 
my head but the table of contents and the index are both shot.  YMMV!  

> On Jun 29, 2017, at 16:09, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> What, then, was the scope of an allocation?  Of an ENQ?  What happened if
> multiple users concurrently ALLOCATEd SYSUT2?  I suppose carefully avoiding
> RET=HAVE could keep the DSN spaces separate.  And users would just need to
> deal with that and the "IKJ56246I type_name NOT ALLOCATED, FILE IN USE"
> condition.

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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Paul Gilmartin]

On Thu, 29 Jun 2017 19:23:31 +, J R wrote:

>Well, it's a long, long time ago, but I seem to remember that many TSO 
>sessions would share a TSO Region, which was a single job. (No address spaces 
>then.).   If you had lots of TSO users, and sufficient horsepower, you would 
>run multiple TSO Regions. 
> 
What, then, was the scope of an allocation?  Of an ENQ?  What happened if
multiple users concurrently ALLOCATEd SYSUT2?  I suppose carefully avoiding
RET=HAVE could keep the DSN spaces separate.  And users would just need to
deal with that and the "IKJ56246I type_name NOT ALLOCATED, FILE IN USE"
condition.

-- gil

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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Gibney, Dave]

I wasn't there, but prior to TSO, there weren't any interactive users to send 
messages to. What purpose would a SYS!.BRODCAST serve in a card reader era?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Thursday, June 29, 2017 12:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: JES2 Exit 16 (was Re: how to keep messages in the
> sys1.broadcast for ever)
> 
> On 2017-06-29, at 13:03, J R wrote:
> 
> > The original API for dynamic allocation was DAIR.
> >
> ISTR "IKJDAIR".  Does this imply TSO is a requisite?  This could have been
> onerous in an era when TSO was not bundled, or even if DAIR could be used
> only under the TMP.
> 
> >> On Jun 29, 2017, at 13:13, John McKown wrote:
> >>
> >> ​This originated back is MVT days. MVT did not really have an API for
> >> dynamic allocation. The data set was "fake opened" (i.e. code other
> >> than OPEN found the DSN & extents, and built an "open" DCB and
> >> associated DEB.)​
> 
> -- 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: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[J R]

Well, DAIR was invented for TSO and required TSO calling parameters when 
invoked. (PSCB, UPT, etc).  However, MVS introduced one address space per TSO 
user (no TSO regions) and the distinction between TSO users and other job types 
became blurred.  This included DYNALLOC which was/is not dependant on TSO 
control blocks. 

> On Jun 29, 2017, at 15:17, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> ISTR "IKJDAIR".  Does this imply TSO is a requisite?  This could
> have been onerous in an era when TSO was not bundled, or even if
> DAIR could be used only under the TMP.

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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[J R]

Well, it's a long, long time ago, but I seem to remember that many TSO sessions 
would share a TSO Region, which was a single job. (No address spaces then.).   
If you had lots of TSO users, and sufficient horsepower, you would run multiple 
TSO Regions. 

On Jun 29, 2017, at 15:15, John McKown  wrote:

>> More likely that all I/O was done in a TMP task that supported requests
>> from the SEND and LISTBC commands.
>> 
> 
> Console operator SEND? But, again, that was so long ago that I could easily
> be having "critical ECC memory failure".

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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Paul Gilmartin]

On 2017-06-29, at 13:03, J R wrote:

> The original API for dynamic allocation was DAIR.  
>  
ISTR "IKJDAIR".  Does this imply TSO is a requisite?  This could
have been onerous in an era when TSO was not bundled, or even if
DAIR could be used only under the TMP.

>> On Jun 29, 2017, at 13:13, John McKown wrote:
>> 
>> ​This originated back is MVT days. MVT did not really have an API for
>> dynamic allocation. The data set was "fake opened" (i.e. code other than
>> OPEN found the DSN & extents, and built an "open" DCB and associated DEB.)​

-- gil

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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[John McKown]

On Thu, Jun 29, 2017 at 2:12 PM, J R  wrote:

> More likely that all I/O was done in a TMP task that supported requests
> from the SEND and LISTBC commands.
>

Console operator SEND? But, again, that was so long ago that I could easily
be having "critical ECC memory failure".



>
> > On Jun 29, 2017, at 13:13, John McKown 
> wrote:
> >
> > The DCB was in common storage so that the SEND command could just write
> to
> > the DSN using it.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

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: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[J R]

More likely that all I/O was done in a TMP task that supported requests from 
the SEND and LISTBC commands. 

> On Jun 29, 2017, at 13:13, John McKown  wrote:
> 
> The DCB was in common storage so that the SEND command could just write to
> the DSN using it.

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

Re: Logstreams

[Jesse 1 Robinson]

Aha. I didn't know about specifying 'LOGSTREAM' in IEASYSxx. I wonder about our 
DR situation though. We cannot create any logstream until the first system is 
up and running...

.
.
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 Skeldum, William
Sent: Thursday, June 29, 2017 9:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logstreams

We use logstreams, including for logrec and do not have any SYS1.LOGREC 
datasets defined.  Our IEASYSxx parmlib specifies LOGREC=LOGSTREAM.  We have no 
issues IPLing.  Early in the IPL we receive message:
IFB085I LOGREC RECORDING TO LOG STREAM SYSPLEX.LOGREC.ALLRECS Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Wilkie
Sent: Thursday, June 29, 2017 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

Thanks, and yes, It does fail without sys1.logrec.


I can't believe the system can't come up without LOGREC. I would think it 
should issue messages but at least let you IPL.  Once you're up you can 
allocate a new one.  Maybe Z/os could even dynamically allocate one and just 
keep going.


From what I can gather so far about Logstreams, it just holds a bunch of 
different logs like Operlog, LOGREC, etc. but the data is still in it's 
original form as if it were read directly from the original data set.


Bill



From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Thursday, June 29, 2017 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

Logstream cannot substitute for the LOGREC data set at IPL, which others 
suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It 
is however named in IEASYSxx, where we have coded 
LOGREC=SYS1.LOGREC.$SYS ever since we moved to sysplex in the mid-90s. 
I cannot recall trying to IPL without LOGREC, but I imagine it would fail.

There are good reasons for moving to logstream, but the ability to IPL is not 
one of them.

.
.
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 Lizette Koehler
Sent: Thursday, June 29, 2017 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logstreams

So does this mean the problem you are trying to solve by asking about 
logstreams is

Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?  Will 
the logstream still allow me to IPL eve if SYS1.LOGREC is gone?

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 5:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> Lizette:
>
>
> I am not using logstreams yet. I am just looking into it.
>
>
> The SYS1.LOGREC data set got deleted on our test system so we couldn't 
> IPL it. We ran a job from our other system to create a new one and it IPL'd 
> OK.
>
>
> Thanks
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Lizette Koehler 
> Sent: Thursday, June 29, 2017 12:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> When you say you deleted a logstream - which one?
>
> If it is for Logrec, did you have the SYS1.LOGREC dataset still 
> cataloged and on the system?
>
> What was the corrective action that allowed you to IPL
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 2:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > We accidentally deleted Logrec on one system, and couldn't IPL. Not 
> > sure if logstream being available would have made a difference.
> >
> >
> > Bill
> >


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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[J R]

The original API for dynamic allocation was DAIR.  

> On Jun 29, 2017, at 13:13, John McKown  wrote:
> 
> ​This originated back is MVT days. MVT did not really have an API for
> dynamic allocation. The data set was "fake opened" (i.e. code other than
> OPEN found the DSN & extents, and built an "open" DCB and associated DEB.)​

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

Re: Logstreams

[Jesse 1 Robinson]

I do have the dimmest memory of IPLing a new LPAR that did not yet have a 
SYS LOGREC. (Disclaimer: all my memories are dim.) Perhaps the system 
prompted for a usable LOGREC data set, or at least the volser of the named guy. 
But I think we've established that you will not IPL without some LOGREC data 
set available.

Note that this is not true for other logstream recording mechanisms like SMF 
and OPERLOG. A system will limp along with no usable MANx data set; also with 
no functioning OPERLOG. In fact this happens to us every time we bring up our 
DR systems for the first time--without any defined logstreams. You can create a 
logstream only on the exploiting system. So we IPL, then run the log stream 
creation jobs for SMF, OPERLOG, and RRS.

.
.
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 Gibney, Dave
Sent: Thursday, June 29, 2017 11:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logstreams

It will come up with LOGREC full :) 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 9:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
> 
> Thanks, and yes, It does fail without sys1.logrec.
> 
> 
> I can't believe the system can't come up without LOGREC. I would think 
> it should issue messages but at least let you IPL.  Once you're up you 
> can allocate a new one.  Maybe Z/os could even dynamically allocate 
> one and just keep going.
> 
> 
> From what I can gather so far about Logstreams, it just holds a bunch 
> of different logs like Operlog, LOGREC, etc. but the data is still in 
> it's original form as if it were read directly from the original data set.
> 
> 
> Bill
> 
> 
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Jesse 1 Robinson 
> Sent: Thursday, June 29, 2017 3:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
> 
> Logstream cannot substitute for the LOGREC data set at IPL, which 
> others suggest is required. I checked our MSTJCLxx, but LOGREC is not named 
> there.
> It is however named in IEASYSxx, where we have coded 
> LOGREC=SYS1.LOGREC.$SYS ever since we moved to sysplex in the 
> mid-90s. I cannot recall trying to IPL without LOGREC, but I imagine 
> it would fail.
> 
> There are good reasons for moving to logstream, but the ability to IPL 
> is not one of them.
> 
> .
> .
> 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 Lizette Koehler
> Sent: Thursday, June 29, 2017 7:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Logstreams
> 
> So does this mean the problem you are trying to solve by asking about 
> logstreams is
> 
> Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?
> Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone?
> 
> Lizette
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 5:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > Lizette:
> >
> >
> > I am not using logstreams yet. I am just looking into it.
> >
> >
> > The SYS1.LOGREC data set got deleted on our test system so we 
> > couldn't IPL it. We ran a job from our other system to create a new 
> > one and it IPL'd
> OK.
> >
> >
> > Thanks
> >
> > Bill
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on 
> > behalf of Lizette Koehler 
> > Sent: Thursday, June 29, 2017 12:45 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > When you say you deleted a logstream - which one?
> >
> > If it is for Logrec, did you have the SYS1.LOGREC dataset still 
> > cataloged and on the system?
> >
> > What was the corrective action that allowed you to IPL
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie
> > > Sent: Thursday, June 29, 2017 2:32 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Logstreams
> > >
> > > We accidentally deleted Logrec on one system, and couldn't IPL. 
> > > Not sure if logstream being available would have made a difference.
> > >
> > >
> > > Bill
> > >


--
For 

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[John McKown]

On Thu, Jun 29, 2017 at 1:34 PM, Jesse 1 Robinson 
wrote:

I get a few of these. From jobs which are submitted by CA-7 and whose JCL
has NOTIFY=

I had two reasons for suppressing superfluous NOTIFY attempts.
>
> -- Several junk messages in syslog each time about trying to find the user
> log, failing, and discarding the message. Over and over for the same
> handful of userids hard-coded into countless jobs.
>
> -- Some obvious though probably trivial overhead of checking for a data
> set that does not now and most likely never will exist.
>
> I did not want to substitute my own overhead. (Note that RACF would not
> know whether the user log exists; only the catalog.)
>
> So I just built a small table of known problem userids. Scan the table. If
> it matches, put out one line of doc. All without the rigmarole of trying to
> change maybe thousands of job streams that have been around for decades.
>
>$HASP954 Exit 16 suppressed NOTIFY for xxx
>
> .
> .
> 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
>
>




-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

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

[Gibney, Dave]

It will come up with LOGREC full :) 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 9:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
> 
> Thanks, and yes, It does fail without sys1.logrec.
> 
> 
> I can't believe the system can't come up without LOGREC. I would think it
> should issue messages but at least let you IPL.  Once you're up you can
> allocate a new one.  Maybe Z/os could even dynamically allocate one and just
> keep going.
> 
> 
> From what I can gather so far about Logstreams, it just holds a bunch of
> different logs like Operlog, LOGREC, etc. but the data is still in it's 
> original
> form as if it were read directly from the original data set.
> 
> 
> Bill
> 
> 
> 
> From: IBM Mainframe Discussion List  on
> behalf of Jesse 1 Robinson 
> Sent: Thursday, June 29, 2017 3:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
> 
> Logstream cannot substitute for the LOGREC data set at IPL, which others
> suggest is required. I checked our MSTJCLxx, but LOGREC is not named there.
> It is however named in IEASYSxx, where we have coded
> LOGREC=SYS1.LOGREC.$SYS ever since we moved to sysplex in
> the mid-90s. I cannot recall trying to IPL without LOGREC, but I imagine it
> would fail.
> 
> There are good reasons for moving to logstream, but the ability to IPL is not
> one of them.
> 
> .
> .
> 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 Lizette Koehler
> Sent: Thursday, June 29, 2017 7:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Logstreams
> 
> So does this mean the problem you are trying to solve by asking about
> logstreams is
> 
> Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?
> Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone?
> 
> Lizette
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 5:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > Lizette:
> >
> >
> > I am not using logstreams yet. I am just looking into it.
> >
> >
> > The SYS1.LOGREC data set got deleted on our test system so we couldn't
> > IPL it. We ran a job from our other system to create a new one and it IPL'd
> OK.
> >
> >
> > Thanks
> >
> > Bill
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Lizette Koehler 
> > Sent: Thursday, June 29, 2017 12:45 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > When you say you deleted a logstream - which one?
> >
> > If it is for Logrec, did you have the SYS1.LOGREC dataset still
> > cataloged and on the system?
> >
> > What was the corrective action that allowed you to IPL
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie
> > > Sent: Thursday, June 29, 2017 2:32 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Logstreams
> > >
> > > We accidentally deleted Logrec on one system, and couldn't IPL. Not
> > > sure if logstream being available would have made a difference.
> > >
> > >
> > > Bill
> > >
> 
> 
> --
> 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: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Jesse 1 Robinson]

I had two reasons for suppressing superfluous NOTIFY attempts. 

-- Several junk messages in syslog each time about trying to find the user log, 
failing, and discarding the message. Over and over for the same handful of 
userids hard-coded into countless jobs.

-- Some obvious though probably trivial overhead of checking for a data set 
that does not now and most likely never will exist.

I did not want to substitute my own overhead. (Note that RACF would not know 
whether the user log exists; only the catalog.)

So I just built a small table of known problem userids. Scan the table. If it 
matches, put out one line of doc. All without the rigmarole of trying to change 
maybe thousands of job streams that have been around for decades.

   $HASP954 Exit 16 suppressed NOTIFY for xxx

.
.
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 John McKown
Sent: Thursday, June 29, 2017 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: JES2 Exit 16 (was Re: how to keep messages in the 
sys1.broadcast for ever)

On Thu, Jun 29, 2017 at 12:34 PM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 29 Jun 2017 12:12:50 -0500, John McKown wrote:
>
> >On Thu, Jun 29, 2017 at 12:07 PM, Paul Gilmartin wrote:
> >
> >> Are entries in SYS1.BRODCAST timestamped so they could be aged out?
> >​No.​
> >
> >​This originated back is MVT days. MVT did not really have an API for 
> >dynamic allocation. The data set was "fake opened" (i.e. code other 
> >than OPEN found the DSN & extents, and built an "open" DCB and 
> >associated
> DEB.)​
> >The DCB was in common storage so that the SEND command could just 
> >write to the DSN using it. Much like what CA-1 does with the TMC.
> >
> Seems like an integrity nightmare.
>

​It was designed long before IBM issued any of their security assurances.​ 
Also, I am saying that is how it was done WAY BACK WHEN. I don't know how it is 
done now. I would __guess__ (SWAG), with individual TSO broadcast data sets, 
that the SEND command now uses standard DYNALLOC / OPEN and so on.


>
> It's past overdue to trade it for a dog, then shoot the dog.
>

​Dog has been upgraded to Cerberus quality.​



>
> >> UNIX facilities could be your friend here, even as UNIX batch jobs
> simply
> >> append their logs to the user's mbox.
>
> -- gil
>

--
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

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: DFSORT to deal with IMS Date/Time

[Sri h Kolusu]

Dirceu Bimonti Ivo,


DFSORT can convert the SMF date and time formats and even perform time 
arithmetic. Is IMSLOG data similar to SMF data?  Can you send me a sample 
input data may be 10 records (to my personal email id)  which would save 
the recreation of input data. Also show a sample of your desired output 
for those 10 sample records.


Thanks,
Kolusu



From:   Dirceu Bimonti Ivo 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/29/2017 10:46 AM
Subject:DFSORT to deal with IMS Date/Time
Sent by:IBM Mainframe Discussion List 



Hi,

Could use some inputs from DFSORT experts. I have this job to sort IMS Log 
Records using an specific criteria, does what it should, I just can't get 
the date/time to display correctly. This is an example of what it looks 
like:

+++++++++++-+-+
| +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +10 | +11 |
+++++++++++-+-+
| YY | YY | DD | DF | HH | MM | SS | TH | MI | JU | A Q | Q $ |
+++++++++++-+-+
 
2017170F  13361016 8394020D

Translates to 2017.170 13:36:10.168394 UTC -5. Part I am failing is the 
QQ$, which is the offset from UTC in quarter of hour, so x'20D' means 20 
quarter of hour, negative, or -5 hours. I should be subtracting this from 
the HH field, using something like this:

OUTREC FIELDS=(1,4,   * RDW 
   89,1,PD,SUB,   * Hour 
   (95,2,PD,DIV,+4),  * UTC Offset 
   C' ')  * End of Record

It does not work because the offset 89 (HH) is not PD, so one digit gets 
converted to the sign digit instead and the math will be off. While 
looking for a solution to this, I realized that even if it worked, suppose 
the record had HH=01 and UTC=-4, I would get a negative time instead of 
wrapping back to 09 PM.

So, question finally, any way to maybe convert this to a SMF or TOD format 
and properly parse using one of the DATE functions from DFSORT instead ? 
Could probably do this writing a program, it is just easier to quickly 
change the sort parameters or what you want printed in the report using 
DFSORT than actually changing your program.

Thanks in advance.

--
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: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[John McKown]

On Thu, Jun 29, 2017 at 12:34 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 29 Jun 2017 12:12:50 -0500, John McKown wrote:
>
> >On Thu, Jun 29, 2017 at 12:07 PM, Paul Gilmartin wrote:
> >
> >> Are entries in SYS1.BRODCAST timestamped so they could be aged out?
> >​No.​
> >
> >​This originated back is MVT days. MVT did not really have an API for
> >dynamic allocation. The data set was "fake opened" (i.e. code other than
> >OPEN found the DSN & extents, and built an "open" DCB and associated
> DEB.)​
> >The DCB was in common storage so that the SEND command could just write to
> >the DSN using it. Much like what CA-1 does with the TMC.
> >
> Seems like an integrity nightmare.
>

​It was designed long before IBM issued any of their security assurances.​
Also, I am saying that is how it was done WAY BACK WHEN. I don't know how
it is done now. I would __guess__ (SWAG), with individual TSO broadcast
data sets, that the SEND command now uses standard DYNALLOC / OPEN and so
on.


>
> It's past overdue to trade it for a dog, then shoot the dog.
>

​Dog has been upgraded to Cerberus quality.​



>
> >> UNIX facilities could be your friend here, even as UNIX batch jobs
> simply
> >> append their logs to the user's mbox.
>
> -- gil
>

-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

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

DFSORT to deal with IMS Date/Time

[Dirceu Bimonti Ivo]

Hi,

Could use some inputs from DFSORT experts. I have this job to sort IMS Log 
Records using an specific criteria, does what it should, I just can't get the 
date/time to display correctly. This is an example of what it looks like:

+++++++++++-+-+
| +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +10 | +11 |
+++++++++++-+-+
| YY | YY | DD | DF | HH | MM | SS | TH | MI | JU | A Q | Q $ |
+++++++++++-+-+
 
2017170F  13361016 8394020D

Translates to 2017.170 13:36:10.168394 UTC -5. Part I am failing is the QQ$, 
which is the offset from UTC in quarter of hour, so x'20D' means 20 quarter of 
hour, negative, or -5 hours. I should be subtracting this from the HH field, 
using something like this:

OUTREC FIELDS=(1,4,   * RDW  
   89,1,PD,SUB,   * Hour 
   (95,2,PD,DIV,+4),  * UTC Offset   
   C' ')  * End of Record

It does not work because the offset 89 (HH) is not PD, so one digit gets 
converted to the sign digit instead and the math will be off. While looking for 
a solution to this, I realized that even if it worked, suppose the record had 
HH=01 and UTC=-4, I would get a negative time instead of wrapping back to 09 PM.

So, question finally, any way to maybe convert this to a SMF or TOD format and 
properly parse using one of the DATE functions from DFSORT instead ? Could 
probably do this writing a program, it is just easier to quickly change the 
sort parameters or what you want printed in the report using DFSORT than 
actually changing your program.

Thanks in advance.

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

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Paul Gilmartin]

On Thu, 29 Jun 2017 12:12:50 -0500, John McKown wrote:

>On Thu, Jun 29, 2017 at 12:07 PM, Paul Gilmartin wrote:
>
>> Are entries in SYS1.BRODCAST timestamped so they could be aged out?
>​No.​
>
>​This originated back is MVT days. MVT did not really have an API for
>dynamic allocation. The data set was "fake opened" (i.e. code other than
>OPEN found the DSN & extents, and built an "open" DCB and associated DEB.)​
>The DCB was in common storage so that the SEND command could just write to
>the DSN using it. Much like what CA-1 does with the TMC.
> 
Seems like an integrity nightmare.

It's past overdue to trade it for a dog, then shoot the dog.

>> UNIX facilities could be your friend here, even as UNIX batch jobs simply
>> append their logs to the user's mbox.

-- gil

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

Re: Logstreams

[Bill Wilkie]

Thanks, that's nice to KnowBill



From: IBM Mainframe Discussion List  on behalf of 
Skeldum, William 
Sent: Thursday, June 29, 2017 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

We use logstreams, including for logrec and do not have any SYS1.LOGREC 
datasets defined.  Our IEASYSxx parmlib specifies LOGREC=LOGSTREAM.  We have no 
issues IPLing.  Early in the IPL we receive message:
IFB085I LOGREC RECORDING TO LOG STREAM SYSPLEX.LOGREC.ALLRECS
Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Wilkie
Sent: Thursday, June 29, 2017 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

Thanks, and yes, It does fail without sys1.logrec.


I can't believe the system can't come up without LOGREC. I would think it 
should issue messages but at least let you IPL.  Once you're up you can 
allocate a new one.  Maybe Z/os could even dynamically allocate one and just 
keep going.


From what I can gather so far about Logstreams, it just holds a bunch of 
different logs like Operlog, LOGREC, etc. but the data is still in it's 
original form as if it were read directly from the original data set.


Bill



From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Thursday, June 29, 2017 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

Logstream cannot substitute for the LOGREC data set at IPL, which others 
suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It 
is however named in IEASYSxx, where we have coded 
LOGREC=SYS1.LOGREC.$SYS ever since we moved to sysplex in the mid-90s. 
I cannot recall trying to IPL without LOGREC, but I imagine it would fail.

There are good reasons for moving to logstream, but the ability to IPL is not 
one of them.

.
.
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 Lizette Koehler
Sent: Thursday, June 29, 2017 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logstreams

So does this mean the problem you are trying to solve by asking about 
logstreams is

Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?  Will 
the logstream still allow me to IPL eve if SYS1.LOGREC is gone?

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 5:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> Lizette:
>
>
> I am not using logstreams yet. I am just looking into it.
>
>
> The SYS1.LOGREC data set got deleted on our test system so we couldn't
> IPL it. We ran a job from our other system to create a new one and it IPL'd 
> OK.
>
>
> Thanks
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List  on
> behalf of Lizette Koehler 
> Sent: Thursday, June 29, 2017 12:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> When you say you deleted a logstream - which one?
>
> If it is for Logrec, did you have the SYS1.LOGREC dataset still
> cataloged and on the system?
>
> What was the corrective action that allowed you to IPL
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 2:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > We accidentally deleted Logrec on one system, and couldn't IPL. Not
> > sure if logstream being available would have made a difference.
> >
> >
> > Bill
> >


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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 

Re: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[John McKown]

On Thu, Jun 29, 2017 at 12:07 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 29 Jun 2017 11:44:18 -0500, Elardus Engelbrecht wrote:
> >
> >Or what are you using to determine that an id is 'inactive'?
> >
> Are entries in SYS1.BRODCAST timestamped so they could be aged out?
>

​No.​



>
> What was the original design rationale for using a common SYS!.BRODCAST
> rather than individual ?  Allocation/OPEN/CLOSE
> overhead?  ENQ contention?  Space/VTOC constraint?  Other?
>

​This originated back is MVT days. MVT did not really have an API for
dynamic allocation. The data set was "fake opened" (i.e. code other than
OPEN found the DSN & extents, and built an "open" DCB and associated DEB.)​
The DCB was in common storage so that the SEND command could just write to
the DSN using it. Much like what CA-1 does with the TMC.



>
> UNIX facilities could be your friend here, even as UNIX batch jobs simply
> append their logs to the user's mbox.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

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: JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Paul Gilmartin]

On Thu, 29 Jun 2017 11:44:18 -0500, Elardus Engelbrecht wrote:
>
>Or what are you using to determine that an id is 'inactive'?
> 
Are entries in SYS1.BRODCAST timestamped so they could be aged out?

What was the original design rationale for using a common SYS!.BRODCAST
rather than individual ?  Allocation/OPEN/CLOSE
overhead?  ENQ contention?  Space/VTOC constraint?  Other?

UNIX facilities could be your friend here, even as UNIX batch jobs simply
append their logs to the user's mbox.

-- gil

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

Re: Orhan control block in a FIFO chain

[Elardus Engelbrecht]

Donald Likens wrote:

>The follow code supports a FIFO control block chain in CSA. When nothing is in 
>the queue the first and last pointers are zero. It must not be working 
>properly because one of my users gets orphan control blocks periodically.

How does that user know these blocks are 'orphaned'?


>Does anyone see the problem in this code? 

Hard to see, but lets get going...

>CSAMSEGF DSAD  Pointer to FIRST CB 
>CSAMSEGL DSAD  Pointer to last CB in chain
>MSEGNEXT DSAD  NEXT Control block in chain

Please post the full coding. Those comments are not helpful.


> STG   R8,OPERAND1R   (REPLACES CSAMSEGL) 
> XCOPERAND1,OPERAND1  (COMPARISON VALUE)  
> XCOPERAND3,OPERAND3  (COMPARISON VALUE)  
> STG   R8,OPERAND3R   (REPLACES WHERE OPERAND4 POINTS)

... etc. ... 

how are all those OPERAND... filled-in/loaded with values? I'm asking because 
they are defined as DS and I don't see (or missed somehow) how these variables 
are filled-in/loaded with values.

Or are they GETMAINed and then filled in with values?

Are all these ORG statements on a full-word boundary?

Can you post the RMODE + AMODE of those code segment?

Alternatively, can you re-post your question on Assembler-L? There are great 
gurus waiting there to help!

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

[Skeldum, William]

We use logstreams, including for logrec and do not have any SYS1.LOGREC 
datasets defined.  Our IEASYSxx parmlib specifies LOGREC=LOGSTREAM.  We have no 
issues IPLing.  Early in the IPL we receive message:
IFB085I LOGREC RECORDING TO LOG STREAM SYSPLEX.LOGREC.ALLRECS
Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Wilkie
Sent: Thursday, June 29, 2017 10:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

Thanks, and yes, It does fail without sys1.logrec.


I can't believe the system can't come up without LOGREC. I would think it 
should issue messages but at least let you IPL.  Once you're up you can 
allocate a new one.  Maybe Z/os could even dynamically allocate one and just 
keep going.


From what I can gather so far about Logstreams, it just holds a bunch of 
different logs like Operlog, LOGREC, etc. but the data is still in it's 
original form as if it were read directly from the original data set.


Bill



From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Thursday, June 29, 2017 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

Logstream cannot substitute for the LOGREC data set at IPL, which others 
suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It 
is however named in IEASYSxx, where we have coded 
LOGREC=SYS1.LOGREC.$SYS ever since we moved to sysplex in the mid-90s. 
I cannot recall trying to IPL without LOGREC, but I imagine it would fail.

There are good reasons for moving to logstream, but the ability to IPL is not 
one of them.

.
.
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 Lizette Koehler
Sent: Thursday, June 29, 2017 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logstreams

So does this mean the problem you are trying to solve by asking about 
logstreams is

Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?  Will 
the logstream still allow me to IPL eve if SYS1.LOGREC is gone?

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 5:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> Lizette:
>
>
> I am not using logstreams yet. I am just looking into it.
>
>
> The SYS1.LOGREC data set got deleted on our test system so we couldn't
> IPL it. We ran a job from our other system to create a new one and it IPL'd 
> OK.
>
>
> Thanks
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List  on
> behalf of Lizette Koehler 
> Sent: Thursday, June 29, 2017 12:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> When you say you deleted a logstream - which one?
>
> If it is for Logrec, did you have the SYS1.LOGREC dataset still
> cataloged and on the system?
>
> What was the corrective action that allowed you to IPL
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 2:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > We accidentally deleted Logrec on one system, and couldn't IPL. Not
> > sure if logstream being available would have made a difference.
> >
> >
> > Bill
> >


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

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.

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

Re: Logstreams

[Rob Schramm]

Mvs logger - Speed, Sysplex available, transaction loggers

Rob Schramm

On Thu, Jun 29, 2017, 12:21 PM Bill Wilkie  wrote:

> Lizette:
>
>
> I am trying to understand the purpose of the logstream vs Logrec. I am
> just finishing the Logrec manuals and about to read the Logstream Redbook.
>
>
> I was just trying to figure out who was using logstreams and why.
>
>
> Thanks
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Lizette Koehler 
> Sent: Thursday, June 29, 2017 2:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> So does this mean the problem you are trying to solve by asking about
> logstreams is
>
> Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?
> Will the logstream still allow me to IPL eve if SYS1.LOGREC is gone?
>
> Lizette
>
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 5:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > Lizette:
> >
> >
> > I am not using logstreams yet. I am just looking into it.
> >
> >
> > The SYS1.LOGREC data set got deleted on our test system so we couldn't
> IPL
> > it. We ran a job from our other system to create a new one and it IPL'd
> OK.
> >
> >
> > Thanks
> >
> > Bill
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of
> > Lizette Koehler 
> > Sent: Thursday, June 29, 2017 12:45 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > When you say you deleted a logstream - which one?
> >
> > If it is for Logrec, did you have the SYS1.LOGREC dataset still
> cataloged and
> > on the system?
> >
> > What was the corrective action that allowed you to IPL
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > > On Behalf Of Bill Wilkie
> > > Sent: Thursday, June 29, 2017 2:32 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Logstreams
> > >
> > > We accidentally deleted Logrec on one system, and couldn't IPL. Not
> > > sure if logstream being available would have made a difference.
> > >
> > >
> > > Bill
> > >
> > >
>
> --
> 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
>
-- 

Rob Schramm

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

JES2 Exit 16 (was Re: how to keep messages in the sys1.broadcast for ever)

[Elardus Engelbrecht]

Jesse 1 Robinson wrote:

>... In our shop, I got tired years ago of all the failed attempts to send 
>NOTIFY to inactive userids, so I coded a table in JES2 Exit 16 to trash them.

Interesting that you took that approach!

Please educate me if you don't mind please. What RACF macro(s) did you used to 
check whether an id is defined or not?

Or what are you using to determine that an id is 'inactive'?

And how are you 'trashing' these NOTIFYs? Are you replacing the id with a 
'dead' id or what did you do? Or just setting a RC= to tell 
JES2 to behave?

I have a serious need to do that stunt [1], for now we have a 'stupid' job to 
clear out SYS1.BRODCAST every month to keep it 'clean'.


>I must not have had much to do at that time. ;-)  

Now you have much! 

Thanks in advance!

Groete / Greetings
Elardus Engelbrecht

[1] - Some second-hand a$$holes coded NOTIFY= in 
their jobs. They are just Bad, Very Bad Doggies! ;-)

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

Re: Logstreams

[Bill Wilkie]

Lizette:


I am trying to understand the purpose of the logstream vs Logrec. I am just 
finishing the Logrec manuals and about to read the Logstream Redbook.


I was just trying to figure out who was using logstreams and why.


Thanks

Bill



From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Sent: Thursday, June 29, 2017 2:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

So does this mean the problem you are trying to solve by asking about 
logstreams is

Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?  Will 
the logstream still allow me to IPL eve if SYS1.LOGREC is gone?

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 5:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> Lizette:
>
>
> I am not using logstreams yet. I am just looking into it.
>
>
> The SYS1.LOGREC data set got deleted on our test system so we couldn't IPL
> it. We ran a job from our other system to create a new one and it IPL'd OK.
>
>
> Thanks
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List  on behalf of
> Lizette Koehler 
> Sent: Thursday, June 29, 2017 12:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> When you say you deleted a logstream - which one?
>
> If it is for Logrec, did you have the SYS1.LOGREC dataset still cataloged and
> on the system?
>
> What was the corrective action that allowed you to IPL
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 2:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > We accidentally deleted Logrec on one system, and couldn't IPL. Not
> > sure if logstream being available would have made a difference.
> >
> >
> > Bill
> >
> >

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

[Bill Wilkie]

Thanks, and yes, It does fail without sys1.logrec.


I can't believe the system can't come up without LOGREC. I would think it 
should issue messages but at least let you IPL.  Once you're up you can 
allocate a new one.  Maybe Z/os could even dynamically allocate one and just 
keep going.


From what I can gather so far about Logstreams, it just holds a bunch of 
different logs like Operlog, LOGREC, etc. but the data is still in it's 
original form as if it were read directly from the original data set.


Bill



From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Thursday, June 29, 2017 3:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

Logstream cannot substitute for the LOGREC data set at IPL, which others 
suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It 
is however named in IEASYSxx, where we have coded 
LOGREC=SYS1.LOGREC.$SYS ever since we moved to sysplex in the mid-90s. 
I cannot recall trying to IPL without LOGREC, but I imagine it would fail.

There are good reasons for moving to logstream, but the ability to IPL is not 
one of them.

.
.
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 Lizette Koehler
Sent: Thursday, June 29, 2017 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logstreams

So does this mean the problem you are trying to solve by asking about 
logstreams is

Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?  Will 
the logstream still allow me to IPL eve if SYS1.LOGREC is gone?

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 5:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> Lizette:
>
>
> I am not using logstreams yet. I am just looking into it.
>
>
> The SYS1.LOGREC data set got deleted on our test system so we couldn't
> IPL it. We ran a job from our other system to create a new one and it IPL'd 
> OK.
>
>
> Thanks
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List  on
> behalf of Lizette Koehler 
> Sent: Thursday, June 29, 2017 12:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> When you say you deleted a logstream - which one?
>
> If it is for Logrec, did you have the SYS1.LOGREC dataset still
> cataloged and on the system?
>
> What was the corrective action that allowed you to IPL
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 2:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > We accidentally deleted Logrec on one system, and couldn't IPL. Not
> > sure if logstream being available would have made a difference.
> >
> >
> > Bill
> >


--
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: how to keep messages in the sys1.broadcast for ever

[Jesse 1 Robinson]

The canonical solution to a full SYS1.BRODCAST is to stop using it for 
user-directed messages, that is, implement TSO/E SEND user logs. With user logs 
fully implemented, the only messages that go into SYS1.BRODCAST are those 
deliberately placed there by the operator SEND/SAVE command. BROADCAST will 
effectively never fill up again and never need SYNCing. 

With user logs, a NOTIFY (or user-directed SEND) will go into a designated user 
log is one exists, or get discarded if a user log does not exist. That is, SEND 
will not create a new user log. Aside from explicit allocation such as ISPF 
3.2, only the user actually issuing LISTBC will create one. Therefore a user 
who never logs on will not get a user log, which is probably what most shops 
want.  

Someone asked if there is a way to suppress messages for inactive or 
nonexistent userids. User logs will accomplish that without any special coding. 
The system will try to find the user log but fail. In our shop, I got tired 
years ago of all the failed attempts to send NOTIFY to inactive userids, so I 
coded a table in JES2 Exit 16 to trash them. I must not have had much to do at 
that time. ;-) 

.
.
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 Edward Gould
Sent: Wednesday, June 28, 2017 8:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: how to keep messages in the sys1.broadcast for ever

> On Jun 28, 2017, at 10:27 PM, Lizette Koehler  wrote:
> 
> There are commands you can use to update the SYS1.BRODCAST for SAVEd message.
> 
> If you can download the broadcast tool from cbttape.org, it can be helpful.
> 
> To list all messages in the notices section of the SYS1.BRODCAST data 
> set,
> enter:
> 
> SE LIST
> 
> Then you can delete the message by msgno
> 
> Then you can add a new message with the SEND command with the sub parm 
> LOGON
> 
> See this manual for further information.
> 
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo
> s.v2r1.iea
> g100/send.htm
> 
> This was found by going to www.ibm.com  and  searching for 
> SYS1.BRODCAST Lizette
> 

Lizette:

We did what you suggested and it would work  well. The only problem (we did NOT 
have the CBTTAPE program) was that it would occasionally fill up and we had to 
do a SYNC.
People lost messages but as we told them it was their problem. Broadcast was 
only for temporary messages.

Ed


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

Re: Logstreams

[Jesse 1 Robinson]

Logstream cannot substitute for the LOGREC data set at IPL, which others 
suggest is required. I checked our MSTJCLxx, but LOGREC is not named there. It 
is however named in IEASYSxx, where we have coded 
LOGREC=SYS1.LOGREC.$SYS ever since we moved to sysplex in the mid-90s. 
I cannot recall trying to IPL without LOGREC, but I imagine it would fail.

There are good reasons for moving to logstream, but the ability to IPL is not 
one of them.  

.
.
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 Lizette Koehler
Sent: Thursday, June 29, 2017 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logstreams

So does this mean the problem you are trying to solve by asking about 
logstreams is

Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?  Will 
the logstream still allow me to IPL eve if SYS1.LOGREC is gone?

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 5:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
> 
> Lizette:
> 
> 
> I am not using logstreams yet. I am just looking into it.
> 
> 
> The SYS1.LOGREC data set got deleted on our test system so we couldn't 
> IPL it. We ran a job from our other system to create a new one and it IPL'd 
> OK.
> 
> 
> Thanks
> 
> Bill
> 
> 
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Lizette Koehler 
> Sent: Thursday, June 29, 2017 12:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
> 
> When you say you deleted a logstream - which one?
> 
> If it is for Logrec, did you have the SYS1.LOGREC dataset still 
> cataloged and on the system?
> 
> What was the corrective action that allowed you to IPL
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 2:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > We accidentally deleted Logrec on one system, and couldn't IPL. Not 
> > sure if logstream being available would have made a difference.
> >
> >
> > Bill
> >


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

Orhan control block in a FIFO chain

[Donald Likens]

The follow code supports a FIFO control block chain in CSA. When nothing is in 
the queue the first and last pointers are zero. It must not be working properly 
because one of my users gets orphan control blocks periodically. I’ve looked at 
this until my eyes hurt. Does anyone see the problem in this code? Thank you in 
advance for taking the time to look at this problem for me.

CSAMSEGF DSAD  Pointer to FIRST CB 
CSAMSEGL DSAD  Pointer to last CB in chain
MSEGNEXT DSAD  NEXT Control block in chain

Code to add a CB to the chain:
*C   DO UNTIL MSEGCB IS CONNECTED TO THE CHAIN (PLO SERIALIZED)   
DOX378   DS0H 
*  R8 = ADDRESS OF NEW MSEG BEING ADDED   
*C SET R6 = CSAMSEGL  
 LGR6,CSAMSEGL
*C SET CONTECTION INDEX UP BY 1   
 LAR2,1(R2)   
*C IF CSAMSEGF AND CSAMSEGL EQ 0  
*C   SET CSAMSEGF AND CSAMSEGL = NEW MSEGCB ADDRESS   
 STG   R8,OPERAND1R   (REPLACES CSAMSEGL) 
 XCOPERAND1,OPERAND1  (COMPARISON VALUE)  
 XCOPERAND3,OPERAND3  (COMPARISON VALUE)  
 STG   R8,OPERAND3R   (REPLACES WHERE OPERAND4 POINTS)
 LAR0,DCSG
 LGR   R3,R8  
 LAR4,CSAMSEGF
 STG   R4,OPERAND4
 PLO   0,CSAMSEGL,0,PL
* 
*  IF DOUBLE COMPARE AND SWAP IS SPECIFIED, THE FIRSTOPERAND  
*  COMPARISON VALUE AND THE SECOND 
*  OPERAND ARE COMPARED. IF THEY ARE EQUAL, THE
*  THIRD-OPERAND COMPARISON VALUE AND THE FOURTH   
*  OPERAND ARE COMPARED. IF BOTH COMPARISONS INDICATE  
*  EQUALITY, THE FIRST-OPERAND AND THIRD-OPERAND   
*  REPLACEMENT VALUES ARE STORED AT THE SECONDOPERAND  
*  LOCATION AND FOURTH-OPERAND LOCATION,   
*  RESPECTIVELY. IF THE FIRST COMPARISON INDICATES INEQUALITY, 
*  THE SECOND OPERAND IS PLACED IN THE FIRSTOPERAND-   
*  COMPARISON-VALUE LOCATION AS A NEW FIRSTOPERAND 
*  COMPARISON VALUE. IF THE FIRST COMPARISON   
*  INDICATES EQUALITY BUT THE SECOND DOES NOT, THE 
*  FOURTH OPERAND IS PLACED IN THE THIRD-OPERANDCOMPARISON-
*  VALUE LOCATION AS A NEW THIRD-OPERAND   
*  COMPARISON VALUE.   
*  
 BC7,ELIFX378(BRANCH IF NOT SUCCESSFULL)
*C   ELSE  
some logging code not included
 B EIFX378 
ELIFX378 DS0H  
*C IF CSAMSEGL = R6 (ORIGINAL CSAMSEGL VALUE)  
*C   SET CSAMSEGL = POINTER_TO_NEW_MSEG (R8)   
*C   SET MSEGNEXT.OF.LAST.ONCHAIN= POINTER_TO_NEW_MSEG (R8)
 STG   R6,OPERAND1(COMPARISON VALUE)   
 STG   R8,OPERAND1R   (REPLACEMENT VALUE)  
 LAR0,CSSTG 
 LGR   R3,R8
 DROP  R8   
 USING MSEGCB,R6
 LAR4,MSEGNEXT   MSEGNEXT IS IN CSA 
 STG   R4,OPERAND4  
 STG   R8,OPERAND3R 
 PLO   0,CSAMSEGL,0,PL  
*  THE FIRST-OPERAND COMPARISON VALUE AND THE SECOND OPERAND ARE
*  COMPARED.  IF THEY ARE EQUAL, THE FIRST-OPERAND REPLACEMENT VALUE
*  IS STORED AT THE SECOND-OPERAND LOCATION, AND THE THIRD OPERAND IS   
*  STORED AT THE FOURTH-OPERAND LOCATION.   
 BC7,DOX378  (BRANCH IF NOT SUCCESSFUL) 
*C   END 
EIFX378  ds0h


DCSG EQU   9PLO OPERATION DOUBLE COMPARE AND SWAP   
CSSTGEQU   13   PLO OPERATION COMPARE AND SWAP AND STORE
PL   DS0D   PLO PARAMETER LIST  
 ORG   PL+8

Re: Logstreams

[Lizette Koehler]

So does this mean the problem you are trying to solve by asking about 
logstreams is

Can I prevent my system from not IPL'ing if someone deletes SYS1.LOGREC?  Will 
the logstream still allow me to IPL eve if SYS1.LOGREC is gone?

Lizette



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 5:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
> 
> Lizette:
> 
> 
> I am not using logstreams yet. I am just looking into it.
> 
> 
> The SYS1.LOGREC data set got deleted on our test system so we couldn't IPL
> it. We ran a job from our other system to create a new one and it IPL'd OK.
> 
> 
> Thanks
> 
> Bill
> 
> 
> 
> From: IBM Mainframe Discussion List  on behalf of
> Lizette Koehler 
> Sent: Thursday, June 29, 2017 12:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
> 
> When you say you deleted a logstream - which one?
> 
> If it is for Logrec, did you have the SYS1.LOGREC dataset still cataloged and
> on the system?
> 
> What was the corrective action that allowed you to IPL
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Bill Wilkie
> > Sent: Thursday, June 29, 2017 2:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Logstreams
> >
> > We accidentally deleted Logrec on one system, and couldn't IPL. Not
> > sure if logstream being available would have made a difference.
> >
> >
> > Bill
> >
> >

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

Re: DRHSM QUESTION

[willie bunter]

I am authorized to use both
Looking at your suggestion to try HLIST  and let you know how I fared.

On Thu, 6/29/17, Carmen Vitullo  wrote:

 Subject: Re: DRHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, June 29, 2017, 9:56 AM
 
 Are you authorized to the the
 HLIST command ? I forget which one, HSEND ot HLIST requires
 authorization , or did at one time, so 
 
 
 HLIST would work - syntax 
 
 
 HLIST
 DATASETNAME or DATASETNAME(dsname) or LEVEL 
 or LEVEL(qualifier) BOTH - OR - BCDS for backup
 
 
 
 HTH's
 
 
 
 Carmen
 
 
 - Original Message
 -
 
 From: "willie
 bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu>
 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Sent: Thursday, June 29, 2017 7:46:35 AM
 
 Subject: DRHSM QUESTION 
 
 Hallo To All, 
 
 I am trying to get a list of
 all dsns which have a HSM backup. I tried the following
 command but it listed the dsns on ML2. Can someone spot my
 error? 
 
 HSEND LIST DSN
 SELECT(BACKUP) - 
 ODS(PRODD.LIST.ALL.BACKUP)
 
 
 Thanks. 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 access instructions, 
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN 
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

Re: GRS CNS system recommandations

[Joe Gentile]

Hi, 

There is a gdps forum (g...@us.ibm.com) that fields such questions and I 
recommend you reach out there with your question. Have a good day. 

-Joe

Joe Gentile
z/OS Performance

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

Re: DRHSM QUESTION

[Carmen Vitullo]

Are you authorized to the the HLIST command ? I forget which one, HSEND ot 
HLIST requires authorization , or did at one time, so 


HLIST would work - syntax 


HLIST DATASETNAME or DATASETNAME(dsname) or LEVEL 
or LEVEL(qualifier) BOTH - OR - BCDS for backup 


HTH's 


Carmen 

- Original Message -

From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 29, 2017 7:46:35 AM 
Subject: DRHSM QUESTION 

Hallo To All, 

I am trying to get a list of all dsns which have a HSM backup. I tried the 
following command but it listed the dsns on ML2. Can someone spot my error? 

HSEND LIST DSN SELECT(BACKUP) - 
ODS(PRODD.LIST.ALL.BACKUP) 

Thanks. 

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


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

Re: Choosing Windows for your organization should get you fired [Network World]

[R.S.]

W dniu 2017-06-29 o 13:53, Vernooij, Kees (ITOPT1) - KLM pisze:

I'd say: nonsense. A "Social Media Marketing Manager" lecturing technical 
strategies?
The point he is missing, is that Windows is not targeted because it is Windows, 
but because it widely used and therefor efficient to concentrate on. Of course 
no one will write a virus for a DOS BBS system, that is only used at 10 places 
in the world. But if every company moves towards it, the virus writers will 
follow very quickly.


The article is superficial and silly, and you are right the popularity 
drives the number of attacks, however it's not ONLY the popularity.

It's also design.

Let's imagine z/OS is the most popular server in medium and small 
business. Installed on PC server under the only IT person's desk (using 
some preconfigured script). Connected directly to Internet. Will it be 
as easy as Windows to attack?




Regarding personal computers: for TODAY the easiest method to protect 
home users (our ants, wives, grandfathers, kids, etc. ) is to install 
them some kind of Linux. 99% of attack are not apllicable. Majority of 
such user can easily use Linux as they have been using Windows.
A problem with required Windows-only apps can be solved using virtual 
machine or dual boot or swapppable HDD (this is a little bit more 
advanced).
One say: "that's short-sighted, when Linux gets popularity of Windows, 
the number of attacks will be as on Windows today". IMHO not true since 
Linux is more secure by design, HOWEVER IT DOESN'T MATTER, because Linux 
is not as popular as Windows and won't be tomorrow or within next n years.


IMHO last ransomware attacks are good opportunity to say "it wouldn't 
happen on non-Windows platform". And repeat it.


My €0.02

--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: DRHSM QUESTION

[retired mainframer]

Look at the syntax diagram for the LIST command.  The SELECT operand for the 
DSN path does not support a value of BACKUP.  

The same diagram shows that the DSN path defaults to the MCDS which explains 
your results.  However, there is a way to specify you want the info from the 
BCDS. 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of willie bunter
> Sent: Thursday, June 29, 2017 5:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DRHSM QUESTION
> 
> Hallo To All,
> 
> I am trying to get a list of all dsns which have a HSM backup.  I tried the
> following command but it listed the dsns on ML2.  Can someone spot my
> error?
> 
> HSEND LIST DSN SELECT(BACKUP) -
>   ODS(PRODD.LIST.ALL.BACKUP)
>

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

Re: DFHSM QUESTION

[willie bunter]

Sorry, I noticed a typo.  Should have read DFHSM 

On Thu, 6/29/17, willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu> 
wrote:

 Subject: DRHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, June 29, 2017, 8:46 AM
 
 Hallo To All,
 
 I am trying to get a list of all dsns
 which have a HSM backup.  I tried the following command
 but it listed the dsns on ML2.  Can someone spot my
 error?
 
 HSEND LIST DSN SELECT(BACKUP) -  
      
 ODS(PRODD.LIST.ALL.BACKUP)
 
 Thanks.
 
 --
 For IBM-MAIN subscribe / signoff /
 archive access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

Re: Choosing Windows for your organization should get you fired [Network World]

[Paul Gilmartin]

On 2017-06-29, at 05:53, Vernooij, Kees (ITOPT1) - KLM wrote:

> I'd say: nonsense. A "Social Media Marketing Manager" lecturing technical 
> strategies?
> The point he is missing, is that Windows is not targeted because it is 
> Windows, but because it widely used ...
>  
Flouting the ecological principle that diversity engenders robustness.
https://en.wikipedia.org/wiki/Great_Famine_(Ireland)#Potato_dependency

> and therefor efficient to concentrate on. Of course no one will write a virus 
> for a DOS BBS system, that is only used at 10 places in the world. But if 
> every company moves towards it, the virus writers will follow very quickly.
>  
There's an old saying, "No one ever got fired for choosing ..."

I contributed lately to a thread here saying that behaviors suited
for a closed LAN, and facilities that support them, are unsuitable
for the wild Internet.

-- gil

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

Re: Logstreams

[Bill Wilkie]

Lizette:


I am not using logstreams yet. I am just looking into it.


The SYS1.LOGREC data set got deleted on our test system so we couldn't IPL it. 
We ran a job from our other system to create a new one and it IPL'd OK.


Thanks

Bill



From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Sent: Thursday, June 29, 2017 12:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

When you say you deleted a logstream - which one?

If it is for Logrec, did you have the SYS1.LOGREC dataset still cataloged and 
on the system?

What was the corrective action that allowed you to IPL

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 2:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> We accidentally deleted Logrec on one system, and couldn't IPL. Not sure if
> logstream being available would have made a difference.
>
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List  on behalf of
> Jesse 1 Robinson 
> Sent: Wednesday, June 28, 2017 8:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
>
> We don't run regularly with logrec logstream, but I believe that you still
> need to maintain SYS1.LOGREC in order to capture IPL time records that are
> cut before logger gets running. If that's still true...
>
> .
> .
> 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 Pew, Curtis G
> Sent: Wednesday, June 28, 2017 12:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Logstreams
>
> On Jun 28, 2017, at 2:07 PM, Bill Wilkie  wrote:
> >
> > Is anyone running from logstreams instead just running logrec? Using
> logstreams for other reports? How used? Problems?
>
> I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all
> went smoothly and without issues.
>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services
>

--
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: CA7 with service now

[David Crayford]

We use Jira but we're a vendor lab not a production site. Do you run 
cURL directly from NetView or submit a batch job?



On 29/06/2017 7:11 PM, Werner Kuehnel wrote:

Nathan,
I don't know ServiceNow, but we create automatically tickets for abending jobs or 
jobs with RC > 4 in JIRA ticketing system.
This is done with REST services and cURL from a REXX (started by NetView). 
Probably ServiceNow offers also a REST API you can use.
If you need more information please contact me offline.

Regards,
Werner

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Nathan Astle
Gesendet: Donnerstag, 29. Juni 2017 10:06
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: CA7 with service now

Hi,


Is there anyone in the List who have integrated CA7 with Service Now(Ticketing 
Tool). Basically whenever the CA7 jobs Abend it must automatically create a 
incident in service now.

Could you please share your experience  ? So that It can help me to build a 
similar Solution in my Shop.

Nathan

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

[Carmen Vitullo]

I believe you are correct, we added SETLOGRC LOGSTREAM to COMMNDxx member, 
SYS1.LOGREC is still maintained on my systems 
Carmen 


- Original Message -

From: "Jesse 1 Robinson"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, June 28, 2017 3:23:03 PM 
Subject: Re: Logstreams 

We don't run regularly with logrec logstream, but I believe that you still need 
to maintain SYS1.LOGREC in order to capture IPL time records that are cut 
before logger gets running. If that's still true... 

. 
. 
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 Pew, Curtis G 
Sent: Wednesday, June 28, 2017 12:47 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: (External):Re: Logstreams 

On Jun 28, 2017, at 2:07 PM, Bill Wilkie  wrote: 
> 
> Is anyone running from logstreams instead just running logrec? Using 
> logstreams for other reports? How used? Problems? 

I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all went 
smoothly and without issues. 

-- 
Pew, Curtis G 
curtis@austin.utexas.edu 
ITS Systems/Core/Administrative Services 


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

DRHSM QUESTION

[willie bunter]

Hallo To All,

I am trying to get a list of all dsns which have a HSM backup.  I tried the 
following command but it listed the dsns on ML2.  Can someone spot my error?

HSEND LIST DSN SELECT(BACKUP) -  
  ODS(PRODD.LIST.ALL.BACKUP)

Thanks.

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

Re: Logstreams

[Lizette Koehler]

When you say you deleted a logstream - which one?

If it is for Logrec, did you have the SYS1.LOGREC dataset still cataloged and 
on the system?

What was the corrective action that allowed you to IPL

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Wilkie
> Sent: Thursday, June 29, 2017 2:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
> 
> We accidentally deleted Logrec on one system, and couldn't IPL. Not sure if
> logstream being available would have made a difference.
> 
> 
> Bill
> 
> 
> 
> From: IBM Mainframe Discussion List  on behalf of
> Jesse 1 Robinson 
> Sent: Wednesday, June 28, 2017 8:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Logstreams
> 
> We don't run regularly with logrec logstream, but I believe that you still
> need to maintain SYS1.LOGREC in order to capture IPL time records that are
> cut before logger gets running. If that's still true...
> 
> .
> .
> 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 Pew, Curtis G
> Sent: Wednesday, June 28, 2017 12:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Logstreams
> 
> On Jun 28, 2017, at 2:07 PM, Bill Wilkie  wrote:
> >
> > Is anyone running from logstreams instead just running logrec? Using
> logstreams for other reports? How used? Problems?
> 
> I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all
> went smoothly and without issues.
> 
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services
> 

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

Re: AW: CA7 with service now

[Brian France]

Here we use CA-OPS to do this. There's rexx code that looks for certain 
items, can exclude jobs if need be and creates an email that goes to our 
circus now system.



On 6/29/2017 7:11 AM, Werner Kuehnel wrote:

Nathan,
I don't know ServiceNow, but we create automatically tickets for abending jobs or 
jobs with RC > 4 in JIRA ticketing system.
This is done with REST services and cURL from a REXX (started by NetView). 
Probably ServiceNow offers also a REST API you can use.
If you need more information please contact me offline.

Regards,
Werner

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Nathan Astle
Gesendet: Donnerstag, 29. Juni 2017 10:06
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: CA7 with service now

Hi,


Is there anyone in the List who have integrated CA7 with Service Now(Ticketing 
Tool). Basically whenever the CA7 jobs Abend it must automatically create a 
incident in service now.

Could you please share your experience  ? So that It can help me to build a 
similar Solution in my Shop.

Nathan

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


--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

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

Re: Choosing Windows for your organization should get you fired [Network World]

[Vernooij, Kees (ITOPT1) - KLM]

I'd say: nonsense. A "Social Media Marketing Manager" lecturing technical 
strategies?
The point he is missing, is that Windows is not targeted because it is Windows, 
but because it widely used and therefor efficient to concentrate on. Of course 
no one will write a virus for a DOS BBS system, that is only used at 10 places 
in the world. But if every company moves towards it, the virus writers will 
follow very quickly.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark Regan
> Sent: 29 June, 2017 13:43
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Fwd: Choosing Windows for your organization should get you
> fired [Network World]
> 
> From Network World, Choosing Windows for your organization should get
> you
> fired
> 
> http://www.networkworld.com/article/3204156/windows-server/choosing-
> windows-for-your-organization-should-get-you-fired.html
> 
> --
> 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

Fwd: Choosing Windows for your organization should get you fired [Network World]

[Mark Regan]

>From Network World, Choosing Windows for your organization should get you
fired

http://www.networkworld.com/article/3204156/windows-server/choosing-windows-for-your-organization-should-get-you-fired.html

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

AW: CA7 with service now

[Werner Kuehnel]

Nathan,
I don't know ServiceNow, but we create automatically tickets for abending jobs 
or jobs with RC > 4 in JIRA ticketing system.
This is done with REST services and cURL from a REXX (started by NetView). 
Probably ServiceNow offers also a REST API you can use.
If you need more information please contact me offline.

Regards,
Werner

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Nathan Astle
Gesendet: Donnerstag, 29. Juni 2017 10:06
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: CA7 with service now

Hi,


Is there anyone in the List who have integrated CA7 with Service Now(Ticketing 
Tool). Basically whenever the CA7 jobs Abend it must automatically create a 
incident in service now.

Could you please share your experience  ? So that It can help me to build a 
similar Solution in my Shop.

Nathan

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

[Bill Wilkie]

We accidentally deleted Logrec on one system, and couldn't IPL. Not sure if 
logstream being available would have made a difference.


Bill



From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Wednesday, June 28, 2017 8:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logstreams

We don't run regularly with logrec logstream, but I believe that you still need 
to maintain SYS1.LOGREC in order to capture IPL time records that are cut 
before logger gets running. If that's still true...

.
.
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 Pew, Curtis G
Sent: Wednesday, June 28, 2017 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logstreams

On Jun 28, 2017, at 2:07 PM, Bill Wilkie  wrote:
>
> Is anyone running from logstreams instead just running logrec? Using 
> logstreams for other reports? How used? Problems?

I switched SMF, LOGREC, and OPERLOG to logstreams a few years ago. It all went 
smoothly and without issues.

--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

CA7 with service now

[Nathan Astle]

Hi,


Is there anyone in the List who have integrated CA7 with Service
Now(Ticketing Tool). Basically whenever the CA7 jobs Abend it must
automatically create a incident in service now.

Could you please share your experience  ? So that It can help me to build a
similar Solution in my Shop.

Nathan

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