Google Doodle Today

[Linda]

Check out the Google Doodle for today.  :)

"The Antikythera mechanism is an Ancient Greek analog computer and orrery used 
to predict astronomical positions and eclipses calendrical and astrological 
purposes."

Linda

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

Re: setrog lnklst question

[Jesse 1 Robinson]

Not funny. Search Google on 

northern exposure satellite episode

Confirmation not required. 
.
.
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 Mike Schwab
Sent: Wednesday, May 17, 2017 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: setrog lnklst question

This Guy? https://www.themarysue.com/the-sky-is-falling/

... the apparent meteorite struck a college campus in Tamil Nadu in southern 
India. A 40 year old bus driver named Kamaraj died while a student and two 
gardeners nearby were injured. There was an impact crater 4 feet deep 
containing “bluish black” rock fragments, according to the statement from the 
college’s principal, G. Baskar.

Laurie Cantillo, a NASA spokeswoman, said that they’re still testing the object 
to make sure it’s a meteorite and not a random bit of space junk or debris. 
“Our Planetary Defense Coordination Office is aware of the reports and is 
looking into it,” she said. “So at this point the report is unconfirmed.”

On Wed, May 17, 2017 at 3:42 PM, Jesse 1 Robinson  
wrote:
> You can calculate the odds of getting hit by space debris on 5th Avenue, but 
> a nonzero probability would not impel you to live in a bunker. Friday 
> preview: an episode of Northern Exposure centered on the funeral of a fellow 
> who was actually that unlucky. Impossible to find a conventional coffin that 
> could hide all the antennae sticking out in all directions. Morbidly 
> hilarious.
>
> Omegamon (Candle days) provide a dynamic linklist update facility. Offered 
> with all the caveats of the current IBM function. Not sure I ever used it, 
> but I remember ragging on IBM to provide a similar facility many years before 
> they did.
>
> I think it's especially rare that a linklist update would really need JOBS(*) 
> anyway. Dr. Murphy does like to be taunted.
>
> .
> .
> 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 Mark Zelden
> Sent: Wednesday, May 17, 2017 12:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: setrog lnklst question
>
> On Wed, 17 May 2017 19:07:35 +, Jesse 1 Robinson 
>  wrote:
>
>> More important, has anyone actually experienced a problem with JOB(*)?
>
> I don't think that's more important.  What's more important is that the 
> experts at IBM (the people that write the code and have the manuals updated) 
> have stated that it is dangerous.  I don't care if 1000 people on IBM-MAIN say
> they have never had a problem.   Murphy doesn't really like me.  :-)
>
> Besides that, I doubt "DELAY" would have been developed / added for no 
> reason at all because someone felt it would be a good idea just in case to 
> help resolve a theoretical problem.
>
> Regards,
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL 
> v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
> http://www.mzelden.com/mvsutil.html
> Systems Programming expert at 
> http://search390.techtarget.com/ateExperts/
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?


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

Re: setrog lnklst question

[Mike Schwab]

This Guy? https://www.themarysue.com/the-sky-is-falling/

... the apparent meteorite struck a college campus in Tamil Nadu in
southern India. A 40 year old bus driver named Kamaraj died while a
student and two gardeners nearby were injured. There was an impact
crater 4 feet deep containing “bluish black” rock fragments, according
to the statement from the college’s principal, G. Baskar.

Laurie Cantillo, a NASA spokeswoman, said that they’re still testing
the object to make sure it’s a meteorite and not a random bit of space
junk or debris. “Our Planetary Defense Coordination Office is aware of
the reports and is looking into it,” she said. “So at this point the
report is unconfirmed.”

On Wed, May 17, 2017 at 3:42 PM, Jesse 1 Robinson
 wrote:
> You can calculate the odds of getting hit by space debris on 5th Avenue, but 
> a nonzero probability would not impel you to live in a bunker. Friday 
> preview: an episode of Northern Exposure centered on the funeral of a fellow 
> who was actually that unlucky. Impossible to find a conventional coffin that 
> could hide all the antennae sticking out in all directions. Morbidly 
> hilarious.
>
> Omegamon (Candle days) provide a dynamic linklist update facility. Offered 
> with all the caveats of the current IBM function. Not sure I ever used it, 
> but I remember ragging on IBM to provide a similar facility many years before 
> they did.
>
> I think it's especially rare that a linklist update would really need JOBS(*) 
> anyway. Dr. Murphy does like to be taunted.
>
> .
> .
> 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 Mark Zelden
> Sent: Wednesday, May 17, 2017 12:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: setrog lnklst question
>
> On Wed, 17 May 2017 19:07:35 +, Jesse 1 Robinson 
>  wrote:
>
>> More important, has anyone actually experienced a problem with JOB(*)?
>
> I don't think that's more important.  What's more important is that the 
> experts at IBM (the people that write the code and have the manuals updated) 
> have stated that it is dangerous.  I don't care if 1000 people on IBM-MAIN say
> they have never had a problem.   Murphy doesn't really like me.  :-)
>
> Besides that, I doubt "DELAY" would have been developed / added for no reason 
> at all because someone felt it would be a good idea just
> in case to help resolve a theoretical problem.
>
> Regards,
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
> Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
> http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://search390.techtarget.com/ateExperts/
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: setrog lnklst question

[Jesse 1 Robinson]

You can calculate the odds of getting hit by space debris on 5th Avenue, but a 
nonzero probability would not impel you to live in a bunker. Friday preview: an 
episode of Northern Exposure centered on the funeral of a fellow who was 
actually that unlucky. Impossible to find a conventional coffin that could hide 
all the antennae sticking out in all directions. Morbidly hilarious. 

Omegamon (Candle days) provide a dynamic linklist update facility. Offered with 
all the caveats of the current IBM function. Not sure I ever used it, but I 
remember ragging on IBM to provide a similar facility many years before they 
did.

I think it's especially rare that a linklist update would really need JOBS(*) 
anyway. Dr. Murphy does like to be taunted. 

.
.
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 Mark Zelden
Sent: Wednesday, May 17, 2017 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: setrog lnklst question

On Wed, 17 May 2017 19:07:35 +, Jesse 1 Robinson  
wrote:

> More important, has anyone actually experienced a problem with JOB(*)? 

I don't think that's more important.  What's more important is that the experts 
at IBM (the people that write the code and have the manuals updated) have 
stated that it is dangerous.  I don't care if 1000 people on IBM-MAIN say
they have never had a problem.   Murphy doesn't really like me.  :-) 

Besides that, I doubt "DELAY" would have been developed / added for no reason 
at all because someone felt it would be a good idea just 
in case to help resolve a theoretical problem.   

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/


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

Re: Removing JES2 PRT and RMT definitions

[Scott Vetter]

Art,
What about running a second JES2 system on where a production JES2 is already 
running?  It can totally separate from the JES2 production system.  And on that 
test JES2 system you can try removing the PRT and RMT definitian and see what 
happens.
Scott
 

On Wednesday, May 17, 2017 2:04 PM, Art Gutowski  
wrote:
 

 Since the JES2-L list seems to be defunct, and I have not found a conclusive 
answer in the archives nor the books, I'd like to know if a single-member 
warm-start is sufficient to remove PRT(xxx) and RMT(xxx) definitions from a 
MAS, or whether an all-member warm-start is required.  The complex in question 
is a 3-system MAS.  I don't have, at present, a representative test environment 
to play in.  

The requirements for adding and modifying these elements are well-documented, 
requirements for delete are not explicit, IMO.  If I have overlooked a passage, 
please correct my misunderstanding.  I did find a couple of short threads where 
this question was asked, and I see "seems to" and "assume". but nothing that 
says "I tried it and it works".  Does the venerable Mr. Wasik monitor this list?

Thanks,
Art Gutowski
General Motors, LLC

--
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: setrog lnklst question

[Mark Zelden]

On Wed, 17 May 2017 19:07:35 +, Jesse 1 Robinson  
wrote:

> More important, has anyone actually experienced a problem with JOB(*)? 

I don't think that's more important.  What's more important is that the experts
at IBM (the people that write the code and have the manuals updated) have
stated that it is dangerous.  I don't care if 1000 people on IBM-MAIN say
they have never had a problem.   Murphy doesn't really like me.  :-) 

Besides that, I doubt "DELAY" would have been developed / added for
no reason at all because someone felt it would be a good idea just 
in case to help resolve a theoretical problem.   

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: setrog lnklst question

[Jim Mulder]

   Yes, I have spent way too much time looking at dumps that were 
caused by this (enough so that I persuaded Peter Relson to 
make a change in z/OS 2.2 so that a DELAY(1) is done if a delay 
value larger than 1 was not specified).  That has helped a lot. 
But you could easily have a fetching operation that takes
longer than 1 second (or any arbitrary number of seconds) 
due to things like a reserve on the device, or the job getting 
logically swapped due to workload considerations. 

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

> 
> More important, has anyone actually experienced a problem with JOB(*)? 
> 
> .
> .
> 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 Mark Zelden
> Sent: Wednesday, May 17, 2017 10:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: setrog lnklst question
> 
> On Tue, 16 May 2017 23:10:10 +, Gibney, Dave  wrote:
> 
> >And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. 
> >
> >On the other hand, so far, I haven't have need to modify my linklst and 

> >effect all running address spaces. It's usually limited to  a smaller 
subset.
> 
> Yet I continue to see people using it as a matter of habit instead 
> of an "emergency"
> basis.  The only place I have used it regularly is in a sysprog 
> sandbox LPAR and since "delay" was added as an option, I use that 
> along with it.
> 
> LNKLST UPDATE JOB(*) DELAY(5)
> 
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL
> v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
> http://www.mzelden.com/mvsutil.html
> Systems Programming expert at 
http://search390.techtarget.com/ateExperts/
> 
> 
> --
> 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: setrog lnklst question

[Jesse 1 Robinson]

More important, has anyone actually experienced a problem with JOB(*)? 

.
.
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 Mark Zelden
Sent: Wednesday, May 17, 2017 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: setrog lnklst question

On Tue, 16 May 2017 23:10:10 +, Gibney, Dave  wrote:

>And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. 
>
>On the other hand, so far, I haven't have need to modify my linklst and 
>effect all running address spaces. It's usually limited to  a smaller subset.

Yet I continue to see people using it as a matter of habit instead of an 
"emergency"
basis.  The only place I have used it regularly is in a sysprog sandbox LPAR 
and since "delay" was added as an option, I use that along with it.

LNKLST UPDATE JOB(*) DELAY(5)


Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/


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

Removing JES2 PRT and RMT definitions

[Art Gutowski]

Since the JES2-L list seems to be defunct, and I have not found a conclusive 
answer in the archives nor the books, I'd like to know if a single-member 
warm-start is sufficient to remove PRT(xxx) and RMT(xxx) definitions from a 
MAS, or whether an all-member warm-start is required.  The complex in question 
is a 3-system MAS.  I don't have, at present, a representative test environment 
to play in.  

The requirements for adding and modifying these elements are well-documented, 
requirements for delete are not explicit, IMO.  If I have overlooked a passage, 
please correct my misunderstanding.  I did find a couple of short threads where 
this question was asked, and I see "seems to" and "assume". but nothing that 
says "I tried it and it works".  Does the venerable Mr. Wasik monitor this list?

Thanks,
Art Gutowski
General Motors, LLC

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

Re: setrog lnklst question

[Mark Zelden]

On Tue, 16 May 2017 23:10:10 +, Gibney, Dave  wrote:

>And the LNKLST UPDATE JOB(*) is documented as potentially dangerous. 
>
>On the other hand, so far, I haven't have need to modify my linklst and effect 
>all 
>running address spaces. It's usually limited to  a smaller subset. 

Yet I continue to see people using it as a matter of habit instead of an 
"emergency"
basis.  The only place I have used it regularly is in a sysprog sandbox LPAR 
and since
"delay" was added as an option, I use that along with it.

LNKLST UPDATE JOB(*) DELAY(5)


Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables

[Dale R. Smith]

On Tue, 16 May 2017 18:55:25 -0500, Paul Gilmartin  wrote:

>On Tue, 16 May 2017 18:36:38 -0500, Mike Schwab wrote:
>
>>Maybe IBM can publish the info or an II apar to document the
>>application coding techniques causing the problem.
>>
>If move-with-truncation is a conventional COBOL operation,
>the resolution should not be, "Don't do that!"
>
>I detest quiet truncation.  It's hardly better if it takes an
>inordinately long time.
>
>Another possible resolution, with its own performance consequence,
>is for the compiler-generated code to test (every time) whether
>overflow is about to occur and handle it as a special case.  It
>might be better just to abandon the use of DFP.
>
>-- gil

There is a COBOL Compiler option, DIAGTRUNC, that will do the following:
DIAGTRUNC will issue a Warning message for MOVE statements to numeric fields 
when the receiving field has fewer integer positions than the sending field or 
literal.  In statements that have multiple receiving fields, the message is 
issued separately for each field that could be truncated. The message is also 
issued for moves to numeric fields from alphanumeric fields or literals, except 
when the sending field is reference modified.  Will find cases of ‘hidden’ loss 
of data when statements truncate numeric data items.

This is Compile time only, no affect on program execution.

-- 
Dale R. Smith

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

Re: Re. Whacking a Job, or Getting rid of an Address Space

[Sam Golob]

Hi Folks,

I just wish to thank all the contributors to this thread.  I feel 
that every single contribution added to our general knowledge.  Thank 
you all.


This is what the IBM-Main forum is all about.

All the best of everything to all of you.

Sincerely,Sam

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

Re: setrog lnklst question

[william janulin]

Thank you all for your help on my linklst question. I went the 'safe' route and 
built a new lnklst and added the datasets I need for DB2 v12.
Thanks again, Bill J.
 

On Wednesday, May 17, 2017 11:08 AM, Lizette Koehler 
 wrote:
 

 Peter,

Thanks.  That was much clearer than the manual.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: Wednesday, May 17, 2017 4:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: setrog lnklst question
> 
> 
> and the LNKLST UPDATE JOB(*) is documented as potentially dangerous.
> 
> 
> If you're lucky, nothing bad will happen. If you're really unlucky, you will
> trash your system. And all sorts of variants in between.
> The operation is unpredictably dangerous. The effects depend on what happens
> to be going on at the time.
> 
> If you use it, you will get no sympathy (or support) if something bad
> happens. The only safe thing to do is not to use that option.
> New jobs and new address spaces will use the newly activated LNKLST without
> this option.
> 
> You might check out the DELAY sub-option of LNKLST UPDATE. There is no way of
> knowing how long might be necessary to delay before the system is to clean
> up. And the command will not complete until the delay ends.
> 
> Why is it provided at all? Because sometimes you're willing to take a risk if
> your only choice is re-IPL.
> 
> 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


   

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

Re: setrog lnklst question

[Lizette Koehler]

Peter,

Thanks.  That was much clearer than the manual.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: Wednesday, May 17, 2017 4:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: setrog lnklst question
> 
> 
> and the LNKLST UPDATE JOB(*) is documented as potentially dangerous.
> 
> 
> If you're lucky, nothing bad will happen. If you're really unlucky, you will
> trash your system. And all sorts of variants in between.
> The operation is unpredictably dangerous. The effects depend on what happens
> to be going on at the time.
> 
> If you use it, you will get no sympathy (or support) if something bad
> happens. The only safe thing to do is not to use that option.
> New jobs and new address spaces will use the newly activated LNKLST without
> this option.
> 
> You might check out the DELAY sub-option of LNKLST UPDATE. There is no way of
> knowing how long might be necessary to delay before the system is to clean
> up. And the command will not complete until the delay ends.
> 
> Why is it provided at all? Because sometimes you're willing to take a risk if
> your only choice is re-IPL.
> 
> 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

Re: setrog lnklst question

[Jesse 1 Robinson]

One of my favorite campfire routines. 

She: Pa, ya gotcher foot in the fahr.
Pause
She: Pa, ya gotcher foot in the fahr.
Pause
She: (Emphatically) Pa, ya gotcher foot in the fahr!
He: Yeah Ma? Which one?

.
.
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: Tuesday, May 16, 2017 9:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: setrog lnklst question

UPDATE JOB(*) is dangerous.  And was discussed in the IBM MAIN Archives, a 
couple of years ago I think.

However, we use it with no ill effect.



UPDATE
Indicates that the system is to update an address space so that a specified 
job or jobs associated with that space can use the current LNKLST set. If the 
job is using another LNKLST set when the current LNKLST set is activated, it 
will continue to use the original LNKLST set until it completes operations. 
When the job completes and restarts, it then uses the data sets defined in the 
new currently active LNKLST set. See "Removing or Compressing a Data Set in an 
Active LNKLST Set" in z/OS MVS Initialization and Tuning Reference for 
information about LLA management of the LNKLST data set.

Be careful when you use UPDATE. Updating an address space while a program 
in that address space is fetching a module can cause the fetch to fail or to 
locate an incorrect copy of the module. The system does not attempt to verify 
the validity of the data for UPDATE.
Start of changeJOBNAME | JOB=jobnameEnd of change
Specifies the name of the job or jobs to update. You can use wildcard 
characters (? or *) for jobname. UPDATE updates any job whose name matches the 
specified criteria. The system compares jobname to the name of any initiated 
job or jobs that match, or to the name of the address space.



Dangle your foot in the fire.  If it does not burn you are okay, If it does, 
take it out


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Gibney, Dave
> Sent: Tuesday, May 16, 2017 4:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: setrog lnklst question
> 
> And the LNKLST UPDATE JOB(*) is documented as potentially dangerous.
> 
> On the other hand, so far, I haven't have need to modify my linklst 
> and effect all running address spaces. It's usually limited to  a smaller 
> subset.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
> > Sent: Tuesday, May 16, 2017 3:25 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: setrog lnklst question
> >
> > So an EXAMPLE would be
> >
> >/**/
> >/* Adding a dataset to the LINKLIST when it   */
> >/* does not already exist */
> >/**/
> >LNKLST DEFINE NAME(NEWLNKA) COPYFROM(CURRENT)
> >LNKLST ADDNAME(NEWLNKA) DSNAME(SYS1.NEWDSN.INLNK.LIST),
> >AFTER(SYS1.LOCTION.INLNK.LIST)
> >LNKLST DELETE   NAME(NEWLNKA) DSNAME(SYS1.DELETE.THIS.LNKLST.DSN)
> >LNKLST ACTIVATE NAME(NEWLNKA)
> >LNKLST UPDATE JOB(*)
> >APF ADD DSNAME(SYS1.NEWDSN.INLNK.LIST) VOLUME()
> >
> >
> > APF ADD is not needed if the file being added is already APF Authorized.
> > DELETE is not needed if you are not removing anything from the Linklst.
> >
> >
> > Lizette
> >
> > -Original Message-
> > >From: Lizette Koehler 
> > >Sent: May 16, 2017 3:19 PM
> > >To: IBM-MAIN@LISTSERV.UA.EDU
> > >Subject: Re: setrog lnklst question
> > >
> > >You can create a parmlib member to
> > >
> > >COPY the current linklst to a new name Activate the new linklist 
> > >name
> > >
> > >If you need further assistance let us know.
> > >
> > >Lizette
> > >
> > >-Original Message-
> > >>From: william janulin <008d52e04f2e-dmarc-
> > requ...@listserv.ua.edu>
> > >>Sent: May 16, 2017 1:52 PM
> > >>To: IBM-MAIN@LISTSERV.UA.EDU
> > >>Subject: setrog lnklst question
> > >>
> > >>To list;
> > >> Is it possible to add a dataset to the active lnklst? I tried a 
> > >>setprog lnklst
> > add command and got a messagethat the lnklst was active.
> > >>
> > >>Thank you in advance, Bill J.


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

Re: SMF Records

[Charles Mills]

@Kirk, my apologies. There are a couple of SFTP's out there and they are not 
all alike in their SMF approach. You guys did it right! (Don't re-invent the 
wheel.) My thanks.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Wednesday, May 17, 2017 6:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF Records

FYI, Co:Z SFTP supports both Unix files and z/OS data sets and cuts SMF 119 
subtypes 3 and 70, the same as IBM FTP.

https://dovetail.com/docs/sftp/smf-support.html


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, May 17, 2017 at 8:18 AM, Charles Mills  wrote:

> 1. I think you are thinking of other subtypes, one each for SFTP 
> client (3) and server (70). Subtype 7 is the Server port statistics record:
> The Port Statistics record, as an interval record, periodically 
> records statistics on ports that have been configured with the PORT 
> statement in the TCP/IP PROFILE.
> All ports that were defined by the PORTRANGE statement, ports for 
> which the RESERVED flag has been set, or ports that were defined by 
> the PORT UNRSV statement are excluded.
>
> 2. But the OP is using SFTP, so "FTP" SMF records are irrelevant.
>
> Yes, you need to turn on SMF 119 in IP config if you want them.

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

AW: Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables

[Peter Hunkeler]

>The point I was trying to make is that abandoning the use of DFP would not 
>solve
the problem that you experienced.




Sorry for not getting that point.


--
Peter Hunkeler



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

z/OS Connect Enterprise Edition Beta Download Available

[Timothy Sipples]

As a friendly reminder, the z/OS Connect Enterprise Edition open beta is
still available for download, now with a refreshed release:

https://www.ibm.com/support/docview.wss?uid=swg24041739

z/OS Connect provides industry standard, JSON/RESTful interfaces to a broad
range of z/OS-based applications and databases. There many thousands of
public APIs available, and there are already several major z/OS customers
publishing their new APIs into this vast and growing global ecosystem. That
includes, among others, ANZ Bank:

http://www.bankingtech.com/612962/anz-opens-up-apis-to-third-parties/

ANZ is the first major bank to support Apple Pay, notably.

Citibank is another great example, with some details here:

https://myibm.ibm.com/events/interconnect/all-sessions/session/5538A

These banks (and others) are publishing new APIs to generate more revenue
and more profit for their businesses. RESTful APIs are ideal for mobile and
hybrid cloud application expansion. z/OS Connect is probably the most
important new "channel" within the past decade and well worth your time and
attention. Please go grab it and start working it. For more information,
please visit:

https://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102604
https://developer.ibm.com/mainframe/products/zosconnect/


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: SMF Records

[Sasso, Leonard]

Sorry, I was not specific, I meant an MVS Dataset.

Many thanks to everyone, your responses have been very helpful.


Thank You,

Len Sasso
System Administrator


RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn
CSRA
Think Next. Now.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Wednesday, May 17, 2017 9:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF Records

FYI, Co:Z SFTP supports both Unix files and z/OS data sets and cuts SMF 119 
subtypes 3 and 70, the same as IBM FTP.

https://dovetail.com/docs/sftp/smf-support.html


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, May 17, 2017 at 8:18 AM, Charles Mills  wrote:

> 1. I think you are thinking of other subtypes, one each for SFTP
> client (3) and server (70). Subtype 7 is the Server port statistics record:
> The Port Statistics record, as an interval record, periodically
> records statistics on ports that have been configured with the PORT
> statement in the TCP/IP PROFILE.
> All ports that were defined by the PORTRANGE statement, ports for
> which the RESERVED flag has been set, or ports that were defined by
> the PORT UNRSV statement are excluded.
>
> 2. But the OP is using SFTP, so "FTP" SMF records are irrelevant.
>
> Yes, you need to turn on SMF 119 in IP config if you want them.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mike Myers
> Sent: Wednesday, May 17, 2017 3:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF Records
>
> Leonard:
>
> I don't have access to the system any more where I did this, but based
> on the retained documents of the time, I gathered SMF type 119 records
> from TCP/IP. Subtype 7 records contain all data relating to FTP file 
> transfers.
> They give the file name, origin IP address, time stamp (date is
> relative and not in the record), receptor IP address, and file size.
> Filtering on these, I was able to find info on all files FTPed into or
> out of the z/OS box. You should be able to use this by sorting by file
> name to discover your over-writes. If I recall, it didn't matter
> whether the file was a USS or MVS file.
>
> As I recall, I did have to turn on SMF record creation in TCP/IP,
> which were not being generated by default.
>
> --
> 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

This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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

Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables

[Tom Marchant]

On Wed, 17 May 2017 14:59:28 +0200, Peter Hunkeler wrote:

>>I don't believe that this has anything to do with DFP.
>>The decimal overflow exception that Peter reports occurs with Packed
>>Decimal operations, not with Decimal Floating-point operations.
>
>Have a look at the DFP instructions. Some such as CZDT, and CZXT (Convert To 
>Zoned)  
>can indeed raise a decimal overflow exception. There probably are more.

Yes, the Convert to Packed (CPDT and CPXT) and Convert to Zoned (CZDT and 
CZXT) instructions can cause a decimal overflow exception. These are the result 
of the packed or zoned decimal target and not a result of DFP operations.

These are the only DFP instructions that can cause a decimal overflow 
exception. 
As you had noted, decimal overflow can also occur with packed decimal 
arithmetic.

The point I was trying to make is that abandoning the use of DFP would not 
solve 
the problem that you experienced.

-- 
Tom Marchant

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

Re: SMF Records

[Kirk Wolf]

FYI, Co:Z SFTP supports both Unix files and z/OS data sets and cuts SMF 119
subtypes 3 and 70, the same as IBM FTP.

https://dovetail.com/docs/sftp/smf-support.html


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, May 17, 2017 at 8:18 AM, Charles Mills  wrote:

> 1. I think you are thinking of other subtypes, one each for SFTP client (3)
> and server (70). Subtype 7 is the Server port statistics record:
> The Port Statistics record, as an interval record, periodically records
> statistics on
> ports that have been configured with the PORT statement in the TCP/IP
> PROFILE.
> All ports that were defined by the PORTRANGE statement, ports for which the
> RESERVED flag has been set, or ports that were defined by the PORT UNRSV
> statement are excluded.
>
> 2. But the OP is using SFTP, so "FTP" SMF records are irrelevant.
>
> Yes, you need to turn on SMF 119 in IP config if you want them.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Myers
> Sent: Wednesday, May 17, 2017 3:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF Records
>
> Leonard:
>
> I don't have access to the system any more where I did this, but based on
> the retained documents of the time, I gathered SMF type 119 records from
> TCP/IP. Subtype 7 records contain all data relating to FTP file transfers.
> They give the file name, origin IP address, time stamp (date is relative
> and
> not in the record), receptor IP address, and file size.
> Filtering on these, I was able to find info on all files FTPed into or out
> of the z/OS box. You should be able to use this by sorting by file name to
> discover your over-writes. If I recall, it didn't matter whether the file
> was a USS or MVS file.
>
> As I recall, I did have to turn on SMF record creation in TCP/IP, which
> were
> not being generated by default.
>
> --
> 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: SMF Records

[Charles Mills]

1. I think you are thinking of other subtypes, one each for SFTP client (3)
and server (70). Subtype 7 is the Server port statistics record:
The Port Statistics record, as an interval record, periodically records
statistics on
ports that have been configured with the PORT statement in the TCP/IP
PROFILE.
All ports that were defined by the PORTRANGE statement, ports for which the
RESERVED flag has been set, or ports that were defined by the PORT UNRSV
statement are excluded.

2. But the OP is using SFTP, so "FTP" SMF records are irrelevant.

Yes, you need to turn on SMF 119 in IP config if you want them.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike Myers
Sent: Wednesday, May 17, 2017 3:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF Records

Leonard:

I don't have access to the system any more where I did this, but based on
the retained documents of the time, I gathered SMF type 119 records from
TCP/IP. Subtype 7 records contain all data relating to FTP file transfers.
They give the file name, origin IP address, time stamp (date is relative and
not in the record), receptor IP address, and file size. 
Filtering on these, I was able to find info on all files FTPed into or out
of the z/OS box. You should be able to use this by sorting by file name to
discover your over-writes. If I recall, it didn't matter whether the file
was a USS or MVS file.

As I recall, I did have to turn on SMF record creation in TCP/IP, which were
not being generated by default.

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

Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables

[Peter Hunkeler]

>I don't believe that this has anything to do with DFP.
The decimal overflow exception that Peter reports occurs with Packed
Decimal operations, not with Decimal Floating-point operations.





Have a look at the DFP instructions. Some such as CZDT, and CZXT (Convert To 
Zoned)  can indeed raise a decimal overflow exception. There probably are more.


--
Peter Hunkeler

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

Re: ATTACH with RSAPF=YES

[Binyamin Dissen]

In which case you should supply two calls to the non-privileged STC, one which
will get the work element and set the security and a second which will return
results. The calls can be PC's or SVCs.

On Wed, 17 May 2017 14:27:25 +0700 Robin Atwood  wrote:

:>We set the ASXBSENV to the ACEE of the user. The requests are run 
single-threaded, we will have a pool of STCs 
:>available.
:>
:>Robin
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Walt Farrell
:>Sent: 16 May 2017 22:33
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: ATTACH with RSAPF=YES
:>
:>On Tue, 16 May 2017 20:42:42 +0700, Robin Atwood  wrote:
:>
:>>>However, as you're running work on behalf of various end-users, I hope 
you're authenticating those users and >running the work under the proper 
end-user identity in each case. And that would probably require authorization 
>of the STC. 
:>>
:>>Yes, we run under the ACEE of the user.
:>
:>However, unless your STC runs single-threaded (handling requests for only 1 
user at a time) it's not possible for you to run REXX execs invokiing ISPF 
services with proper security. 
:>
:>It would require ensuring that none of the execs, or the services they 
invoke, perform any ATTACH requests., The new subtask created by ATTACH would 
not inherit the ACEE of the user on whose behalf you're running the request. 
(There is one exception to that, but it's used rarely enough that it probably 
won't apply to you. You would have to be using WLM services, and operating as a 
WLM servant to manage the requests that you're processing. Then, and only then 
as far as I know, would the user's ACEE propagate down to a new subtask.)

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: setrog lnklst question

[Peter Relson]

and the LNKLST UPDATE JOB(*) is documented as potentially dangerous.


If you're lucky, nothing bad will happen. If you're really unlucky, you 
will trash your system. And all sorts of variants in between.
The operation is unpredictably dangerous. The effects depend on what 
happens to be going on at the time.

If you use it, you will get no sympathy (or support) if something bad 
happens. The only safe thing to do is not to use that option.
New jobs and new address spaces will use the newly activated LNKLST 
without this option. 

You might check out the DELAY sub-option of LNKLST UPDATE. There is no way 
of knowing how long might be necessary to delay before the system is to 
clean up. And the command will not complete until the delay ends. 

Why is it provided at all? Because sometimes you're willing to take a risk 
if your only choice is re-IPL.

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

AW: Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables

[Peter Hunkeler]

In the meantime I have written a simple standalone Cobol test program to 
experiment with.

First runs did show the 00A program checks in the system trace, but not the 
time and CPU consuming snapshot of the system trace tables. So, while the 00As 
did cost some time in this case, I would not consider it painful.

I wondered why? What was different to our standard environment?

The difference to my simple test case is that it does *not* run under 
Smart/Restart (S/R). So, what negative impact could Smart/Restart have? ... and 
then I remembered that S/R is resetting Language Environment's ESPIE exit, so 
program runs *without* any ESPIE.


Next test case was to run my simple program with LE option TRAP(ON,NOSPIE) to 
simulate the environment of our standard job. The program ran minutes instead 
of a few second. And I did see the system trace snapshots being take in the 
system trace.

So, it seems the 00A program check do not hurt too much by themselves, but they 
need to be handled by an ESPIE exit recognizing it is Cobol, and therefore ok.


--Peter Hunkeler


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

Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables

[Tom Marchant]

On Tue, 16 May 2017 18:55:25 -0500, Paul Gilmartin wrote:

>It
>might be better just to abandon the use of DFP.

I don't believe that this has anything to do with DFP.
The decimal overflow exception that Peter reports occurs with Packed 
Decimal operations, not with Decimal Floating-point operations.

-- 
Tom Marchant

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

AW: Re: Long execution & high CPU usage due to decimal overflow (PGM 00A) and large system trace tables

[Peter Hunkeler]

>>Maybe IBM can publish the info or an II apar to document the
>>application coding techniques causing the problem.
>>
>If move-with-truncation is a conventional COBOL operation,
>the resolution should not be, "Don't do that!"


I agree.


>I detest quiet truncation.  It's hardly better if it takes an
inordinately long time.


I agree.


>Another possible resolution, with its own performance consequence,
is for the compiler-generated code to test (every time) whether
overflow is about to occur and handle it as a special case.  It
might be better just to abandon the use of DFP.




Well, that was what Cobol up to V4 did: Not making use of modern, fast, cache 
protecting instructions. Cobol V5 change this, to the benefit in general, I 
would assume. It is only that truncation may cause pain. BTW, it is not only 
with DFP instructions, it is also with other decimal instructions such as SRP.


--
Peter Hunkeler



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

Re: SMF Records

[Mike Myers]

Leonard:

I don't have access to the system any more where I did this, but based 
on the retained documents of the time, I gathered SMF type 119 records 
from TCP/IP. Subtype 7 records contain all data relating to FTP file 
transfers. They give the file name, origin IP address, time stamp (date 
is relative and not in the record), receptor IP address, and file size. 
Filtering on these, I was able to find info on all files FTPed into or 
out of the z/OS box. You should be able to use this by sorting by file 
name to discover your over-writes. If I recall, it didn't matter whether 
the file was a USS or MVS file.


As I recall, I did have to turn on SMF record creation in TCP/IP, which 
were not being generated by default.


Mike Myers
Vice President
z/OS consultant
Mentor Services Corporation

 On 05/16/2017 05:47 PM, Sasso, Leonard wrote:

A customer transmits, via SFTP, a sequential file, from an external site to an 
IBM Mainframe. An hour later, they transmit the same file with the SAME file 
name, overwriting the original file.

1. What SMF Record Type was cut when the first file was transmitted?

2. Is another SMF Record cut for the overwrite and is it the SAME SMF Record 
Type as the original? If not, what SMF Record Type is cut?



Thank You,

Len Sasso
System Administrator
RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn
CSRA
Think Next. Now.


This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

--
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: ATTACH with RSAPF=YES

[Robin Atwood]

Peter-
Thanks for this, I shall ponder. 

Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 16 May 2017 20:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES


We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which runs APF authorised.


You need to reject that requirement. It cannot be accomplished while
maintaining system integrity. Use of something like "fork" can perhaps
accomplish the goal without meeting the letter of the requirement.


Well, if you want to run unauthorized stuff you would first need to set your
job as non-APF by resetting the bit.


And if you do that, you must *never* turn the bit back on. Turning of
JSCBAUTH is a fairly common approach, once the "authorized stuff" has been
done. But you must then leave it off in order to maintain system integrity.

In all likelihood you should NEVER use RSAPF=YES. It is provided so that the
initiator can attach the jobstep program task. I have no idea why it was
documented. Way back when, even internal things were documented. Maybe when
internal-only things were being removed from the books, no one realized how
internal this one was.

The only z/OS-supported mechanism for authority-decreasing is SYNCH(X). 
And I do intentionally exclude authority-decreasing PC's (e.g., a PC that
gets control in problem state when the invoker was supervisor state)  from
what is supported by z/OS. You can't be stopped from doing so, but things
likely won't behave the way you need if there was a (E)SPIE present. There
might be cases other than (E)SPIE that similarly would cause anomalous
behavior. I have no idea if this is documented explicitly. It's just
something I remember being told long long ago.

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

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

Re: ATTACH with RSAPF=YES

[Robin Atwood]

We set the ASXBSENV to the ACEE of the user. The requests are run 
single-threaded, we will have a pool of STCs 
available.

Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: 16 May 2017 22:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

On Tue, 16 May 2017 20:42:42 +0700, Robin Atwood  wrote:

>>However, as you're running work on behalf of various end-users, I hope you're 
>>authenticating those users and >running the work under the proper end-user 
>>identity in each case. And that would probably require authorization >of the 
>>STC. 
>
>Yes, we run under the ACEE of the user.

However, unless your STC runs single-threaded (handling requests for only 1 
user at a time) it's not possible for you to run REXX execs invokiing ISPF 
services with proper security. 

It would require ensuring that none of the execs, or the services they invoke, 
perform any ATTACH requests., The new subtask created by ATTACH would not 
inherit the ACEE of the user on whose behalf you're running the request. (There 
is one exception to that, but it's used rarely enough that it probably won't 
apply to you. You would have to be using WLM services, and operating as a WLM 
servant to manage the requests that you're processing. Then, and only then as 
far as I know, would the user's ACEE propagate down to a new subtask.)

--
Walt

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

[Vernooij, Kees (ITOPT1) - KLM]

> -Original Message-
> From: Vernooij, Kees (ITOPT1) - KLM
> Sent: 17 May, 2017 8:41
> To: 'IBM Mainframe Discussion List' 
> Subject: RE: SMF Records
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > Behalf Of Jesse 1 Robinson
> > Sent: 17 May, 2017 0:18
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SMF Records
> >
> > Keep in mind that SMF records are cut by applications or components
> that
> > choose to do so. It's not automatic. SMF is a record manager, not a
> > creator. In particular, SFTP is an add-on product that is not related
> to
> > FTP(S) or TCP/IP. It may or may not create SMF records. If it does,
> it's
> > almost certainly the same records type for every transmission.
> >
> > .
> > .
> 
> And in addition to that: look at the SMF manual: SMF 15 is written
> whenever a dataset is CLOSED after being opened for OUTPUT, period.
> Every time a dataset is Closed for output, SMF15 is written, whether it
> was the same dataset or not, the same user or not etc, just the CLOSE
> cuts the record. This allows you to monitor via SMF who opened a dataset
> during some perion, e.g. to determine the one that might have corrupted
> it.
> 
> Kees.

Additional to that: in SMFPRMxx you can specify which records SMF will write 
and which it will not write when the application cuts them and gives them to 
SMF tob e written.

Kees.

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

Re: SMF Records

[Vernooij, Kees (ITOPT1) - KLM]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: 17 May, 2017 0:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF Records
> 
> Keep in mind that SMF records are cut by applications or components that
> choose to do so. It's not automatic. SMF is a record manager, not a
> creator. In particular, SFTP is an add-on product that is not related to
> FTP(S) or TCP/IP. It may or may not create SMF records. If it does, it's
> almost certainly the same records type for every transmission.
> 
> .
> .

And in addition to that: look at the SMF manual: SMF 15 is written whenever a 
dataset is CLOSED after being opened for OUTPUT, period. 
Every time a dataset is Closed for output, SMF15 is written, whether it was the 
same dataset or not, the same user or not etc, just the CLOSE cuts the record. 
This allows you to monitor via SMF who opened a dataset during some perion, 
e.g. to determine the one that might have corrupted it.

Kees.

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