Re: DFSORT Header1 with Date

[Sri h Kolusu]

Gilson,


DFSORT does NOT support date arithmetic on Header/Trailers. However it is
an easy fix as you just need to add an INREC/OUTREC to get the desired
results.  Basically we add the Current date-1 using OUTREC at a temporary
position say in this case 1501 ( as your LRECL is 1500) and then use it in
the header1  control cards.

Use the following DFSORT control cards which will give you the desired
results.

//SYSINDD *
  OPTION COPY
  OUTREC OVERLAY=(1501:DATE1-1)

  OUTFIL REMOVECC,INCLUDE=(1,1,CH,EQ,C'1'),
  HEADER1=(C'H',DATENS(4MD),TIMENS(24),1501,8),
  OUTREC=(C'DW',1,1269)
/*


Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on
09/24/2019 03:50:07 AM:

> From: Gilson Cesar de Oliveira 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 09/24/2019 03:51 AM
> Subject: [EXTERNAL] Re: DFSORT Header1 with Date
> Sent by: IBM Mainframe Discussion List 
>
> Dear list:
>
>   Follow the results using DFSORT:
> ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS,
> EXAMPLES AND MORE
> ICE000I 0 - CONTROL STATEMENTS FOR 5650-ZOS, Z/OS DFSORT V2R3  - 06:
> 00 ON SUN SEP 22, 2019 -
>OPTION COPY

>OUTFIL FNAMES=SORTOUT,REMOVECC,INCLUDE=(1,1,CH,EQ,C'1'),

>HEADER1=(C'H',DATENS(4MD),TIMENS,DATENS(4MD)-1),

>$

> ICE007A 1 SYNTAX ERROR

>TRAILER1=(C'T',COUNT+2=(M11,LENGTH=10)),

>$

> ICE005A 0 BLANK NEEDED IN COLUMN 1 OR OPERATION NOT DEFINED
> CORRECTLY
>OUTREC=(C'D',

>  $

> ICE007A 1 SYNTAX ERROR

>C'W',

> $

>
>
> The problem is in HEADER1 where it doesn't recognise DATENS(4MD)-1
syntax.
>
> The input file has the following:
> RECFM=FB
> LRECL=1500
>
> The content is the following:
> 0021252019092300
> 14070414842360259994070004320324974844070004320324974800
> 140786381980020499940700043203286872920034070004320328687292
> 140790365278068099940700040043713848550064070004004371384855
> 140728887336531009940700043203262145410094070004320326214541
> 140785842023864349940700043203267612270024070004320326761227
> 140703667305626689940700043203224981010084070004320322498101
> 140728041106581529940700043203250917610034070004320325091761
>
>
> The OUTPUT file (SORTOUT) has the following format:
>
> RECFM=FB
> LRECL=1271
>
> The content in the SORTOUT is the following:
>
> H2019092106001820190920
> DW4070371144234620994070004320325220398008407000432032522039813
> DW4078902827390507994070004320328121127005407000432032812112714
> DW4072801894591151994070004320325054784000407000432032505478413
> DW4070340219305668994070004320325749122004407000432032574912212
> DW4078504750297550994070004320326695168009407000432032669516812
> DW4078625679686015994070004320328530484005407000432032853048412
> DW4070336669482787994070004320325770420004407000432032577042014
>
> The syntax when using SYNCSORT runs fine.
>
> When using DFSORT there is a syntax error and we are researching for
> an alternative using it.
>
>
> Regards,
>
> Gilson
>
> --
> 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: EMC DLM Switch failure - Is there a way to set H/W failure alerts?

[RCG]

Thanks much 😊😊

On Thu, Oct 3, 2019, 1:07 AM Dana Mitchell  wrote:

> EMC DLMs support both SNMP and email alert notifications.
>
> Dana
>
> On Wed, 2 Oct 2019 10:38:20 +0530, RCG  wrote:
>
> >Hi Experts, Can you please shed some light on setting up H/W alerts on
> >Mainframes, We had a situation where one of the two DLM switch failed 2
> >weeks ago and before we plan a change to replace that, second one failed
> as
> >well resulting in DLM outage :(
> >
> >Regards,
> >
> >--
> >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: Another IBM Mainframe bites the dust

[Jack J. Woehr]

On 10/2/19 5:27 PM, Thomas Kern wrote:

My condolences.

/Tom Kern
/former z/VM Systems Programmer


On 10/02/2019 13:56, Honeycutt,Mary C wrote:

Hi All,

After 47 years, The University of Florida, Has shut down our Mainframe. 


If everyone's not too busy, there's a shortage of Cobol and RPG 
programmers in the IBM i community ...


Not like you  have to learn new skills. Just new old skills :)

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: IBM SSI Function Codes 16 and 17

[Charles Mills]

I looked at my OS/390 V2R8 doc and it was not in there. That is the oldest
that I have AFAIK.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Wednesday, October 2, 2019 4:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM SSI Function Codes 16 and 17

I took a look at bitsavers but it looks like there is no copy there of the
old MVS SSI documentation. IBM dropped a lot of information in OS/390,
possibly earlier.

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

Re: Another IBM Mainframe bites the dust

[Thomas Kern]

My condolences.

/Tom Kern
/former z/VM Systems Programmer


On 10/02/2019 13:56, Honeycutt,Mary C wrote:

Hi All,

After 47 years, The University of Florida, Has shut down our Mainframe.

Thanks,

Cathy Honeycutt

Systems Admin/Programmer III
720 SW 2nd Avenue
Gainesville, FL 32603
flga...@ufl.edu
352 273-1328
MVS - CICS


--
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: Planned ESQA change and HealthCheck

[Seymour J Metz]

I've found that foreigners who learned English in school often speak better 
English than native Anglophones but make certain characteristic grammatical 
errors (different errors for different native languages.) 


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Richards, Robert B. <01c91f408b9e-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, October 1, 2019 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Planned ESQA change and HealthCheck

Skip,

I have found that a lots of "English as a second language" folks speak better 
English than the rest of us. I had to refresh my memory using the dictionary 
when Radoslaw trotted out "anathematized". I *hate* it when people do that! 


I stand in awe behind you.  :-)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, October 1, 2019 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Planned ESQA change and HealthCheck

I stand in awe of the Polish guru who can both entertain and educate. Including 
English vocabulary. No anathematization here.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Tuesday, October 1, 2019 7:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Planned ESQA change and HealthCheck

(I will be anathematized for the text below) Simple solution:
stop HZSPROC
delete HZSDATA dataset
create it again using plain IEFBR14 or any other method - just empty PS dataset 
start HZSPROC

It works. No animal will be injured by deletion of the dataset. No climate 
change will happen when you create new dataset using cursed method as the 
above. Some prophets say it may happen badly, but it had never happened yet...


--
Radoslaw Skorupka
Lodz, Poland






W dniu 2019-10-01 o 13:25, Jousma, David pisze:
> Ok, I answered the first question.  How to get it back, F HZSPROC,ADDNEW.   
> But how do I reset the history is still outstanding.
>
> Thanks, Dave
>
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jousma, David
> Sent: Tuesday, October 1, 2019 7:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Planned ESQA change and HealthCheck
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> Ok,  This is one of those dumb moments...IPLed one of my tech systems last 
> night with a planned increase of ESQA.   The associated health check popped 
> after the IPL  CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease in EPVT.  
>  It's not clear to me how to reset the history for this healthcheck so that 
> it doesn't show as a critical problem.   In my guessing, I ended up deleting 
> that check.
>
> So how do I get it back(short of IPLing), and how do I reset the history 
> since this was a planned change?
>

--
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: IBM SSI Function Codes 16 and 17

[Seymour J Metz]

I took a look at bitsavers but it looks like there is no copy there of the old 
MVS SSI documentation. IBM dropped a lot of information in OS/390, possibly 
earlier.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Lionel B Dyck 
Sent: Wednesday, October 2, 2019 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM SSI Function Codes 16 and 17

I'm interested in utilizing SSI Function codes 16 (data set open) and 17
(data set close) but I'm not able to find any information on how to use
these. In looking at the IBM z/OS 2.4 publication on the SSI these are not
even included in the list of 'allowed' function codes.



Can anyone point me to where I can find out more about how to use these
function codes in my subsystem?



Thank you





Lionel B. Dyck <
Website:  

 
http://secure-web.cisco.com/1ZvArWQLTrpHn8yobRVbOrSpPvK2pNCNaBaALzJiSRvSMd1DeBsqbiw47UrEt5vzjagXdExg_USKQSY7HmrMn85odxL3ZCDk5maz1BtWenyduApsox1jTCfTKuv_U_79E1EQ0JsYaXiNAcjxT4VBkKAO6AztjJ9znIct4UnIvSTH22km1oWvxs9LQE2z5wNSm9KJq1_Zqq0EB0IohZDI6E202sfSOVH_8xhbVCBiNLB7g1e0Bq5sbbIXevB_sswL4FRRY3LPY1zNurjiceLX-O0gzvBTAvFNkhaEaCuwXBkfxaw9ExR6PdbK7Tx8QQwDzqh3GxEKyB4PMWfMthtfF04NW_2vbGGJdHwEixkAQaNpeCOcjeVzvJp8x7CziaUik/http%3A%2F%2Fwww.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden




--
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: Phoenix Software International Announces IBM?? JES3 Licensing Agreement

[Don Poitras]

Just wow.

In article  you wrote:
> El Segundo, CA???October 2, 2019: Phoenix Software International, Inc., 
> today announced they have entered into an agreement with IBM?? under 
> which Phoenix Software International has licensed the source code for 
> IBM???s z/OS JES3 spooling subsystem, offering a solution to clients 
> wishing to remain on JES3.

> Read the press release here: http://bit.ly/spooler-news

> -- 
> Phoenix Software International
> Edward E. Jaffe
> Chief Technology Officer
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Phoenix Software International Announces IBM® JES3 Licensing Agreement

[Ed Jaffe]

El Segundo, CA—October 2, 2019: Phoenix Software International, Inc., 
today announced they have entered into an agreement with IBM® under 
which Phoenix Software International has licensed the source code for 
IBM’s z/OS JES3 spooling subsystem, offering a solution to clients 
wishing to remain on JES3.


Read the press release here: http://bit.ly/spooler-news

--
Phoenix Software International
Edward E. Jaffe
Chief Technology Officer
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: multi-line STDPARM shell script for BPXBATCH

[Peter Bishop]

Fully agree about the "too many solutions".  If I could just use COZBATCH 
everywhere by default, I would, but I'm stuck with BPXBATCH and can now at 
least comment the multi-line shell scripts it supports, subject to correct 
placement of semicolons and other "mangled" shell and JCL.

The bit that bit me was the sparsely-documented semicolons ('do' and 'for' 
especially tricky) and the "EOF" from the '#' comment.  Once bitten twice shy  
:-)

Thanks also to John M for his awk example which was educational.

best regards,
Peter

On Wed, 2 Oct 2019 15:02:29 -0500, Paul Gilmartin  wrote:

>On Wed, 2 Oct 2019 14:52:32 -0500, Kirk Wolf wrote:
>
>>You really like all of this mangling of the shell syntax?
>>What about "here" documents (quoted or otherwise) ?
>>The addition of STDPARM only makes it suck slightly less than before :-)
>>
>>For heaven's sake, why doesn't it just read the input from DD:STDIN and
>>then send that to fd0 of the /bin/sh process?
>>
>BPXWUNIX can do that.
>Too many incomplete solutions.
>
>>That should be required for a passing grade.   Extra credit if you can get
>>it to run /bin/sh as a *login* shell in the same address space, but not
>>much.
>> 
>AOPBATCH.  But IBM doesn't give it away.
>Long ago, I posted my BPXWUNIX wrapper at:
>http://vm.marist.edu/htbin/wlvtype?MVS-OE.26963
>
>Some of the mangling I did there is now unnecessary with more
>recent enhancements to BPXWUNIX.
>
>-- 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: multi-line STDPARM shell script for BPXBATCH

[Paul Gilmartin]

On Wed, 2 Oct 2019 14:52:32 -0500, Kirk Wolf wrote:

>You really like all of this mangling of the shell syntax?
>What about "here" documents (quoted or otherwise) ?
>The addition of STDPARM only makes it suck slightly less than before :-)
>
>For heaven's sake, why doesn't it just read the input from DD:STDIN and
>then send that to fd0 of the /bin/sh process?
>
BPXWUNIX can do that.
Too many incomplete solutions.

>That should be required for a passing grade.   Extra credit if you can get
>it to run /bin/sh as a *login* shell in the same address space, but not
>much.
> 
AOPBATCH.  But IBM doesn't give it away.
Long ago, I posted my BPXWUNIX wrapper at:
http://vm.marist.edu/htbin/wlvtype?MVS-OE.26963

Some of the mangling I did there is now unnecessary with more
recent enhancements to BPXWUNIX.

-- gil

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

Re: multi-line STDPARM shell script for BPXBATCH

[Kirk Wolf]

You really like all of this mangling of the shell syntax?
What about "here" documents (quoted or otherwise) ?
The addition of STDPARM only makes it suck slightly less than before :-)

For heaven's sake, why doesn't it just read the input from DD:STDIN and
then send that to fd0 of the /bin/sh process?
That should be required for a passing grade.   Extra credit if you can get
it to run /bin/sh as a *login* shell in the same address space, but not
much.


On Wed, Oct 2, 2019 at 1:22 PM John McKown 
wrote:

> On Wed, Oct 2, 2019 at 1:15 PM Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On Wed, 2 Oct 2019 11:58:35 -0500, John McKown wrote:
> > >>
> > >Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!
> > >
> > Easy enough when you have only one shell command and no comments.
> >
>
> You can do multiple shell commands by using the semi-colon "end of command"
> character. But you're very correct about no comments. Well, sort of. there
> is the "colon" command which is the equivalent of IEFBR14 in batch.
>
> SH cd /tmp2;
>pwd;
>: sort of a comment;
>ls -l;
>
> Will work too. Output from above:
>
> /LIH1/tmp2
> total 2
> drwxr-x--- 3 AXRUSER  TSHG 288 Oct 13  2016 AXRUSER
>
>
> --
> I find television very educational. The minute somebody turns it on, I go
> into the library and read a good book
> -- Groucho Marx
>
> Maranatha! <><
> John McKown
>
> --
> 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: EMC DLM Switch failure - Is there a way to set H/W failure alerts?

[Dana Mitchell]

EMC DLMs support both SNMP and email alert notifications.

Dana

On Wed, 2 Oct 2019 10:38:20 +0530, RCG  wrote:

>Hi Experts, Can you please shed some light on setting up H/W alerts on
>Mainframes, We had a situation where one of the two DLM switch failed 2
>weeks ago and before we plan a change to replace that, second one failed as
>well resulting in DLM outage :(
>
>Regards,
>
>--
>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: EMC DLM Switch failure - Is there a way to set H/W failure alerts?

[RCG]

I'm checking on this and will share an update please

On Wed, Oct 2, 2019, 3:22 PM Attila Fogarasi  wrote:

> SNMP is the normal mechanism ... does EMC DLM not support that (hard to
> believe), was it misconfigured to not issue the SNMP alert, or are you not
> running software to process SNMP and process as appropriate?  This is
> pretty standard and not mainframe specific, but there are good mainframe
> based SNMP handlers such as from Broadcom (Vantage product).
>
> On Wed, Oct 2, 2019 at 3:08 PM RCG  wrote:
>
> > Hi Experts, Can you please shed some light on setting up H/W alerts on
> > Mainframes, We had a situation where one of the two DLM switch failed 2
> > weeks ago and before we plan a change to replace that, second one failed
> as
> > well resulting in DLM outage :(
> >
> > Regards,
> >
> > --
> > 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: IBM SSI Function Codes 16 and 17

[Wayne Driscoll]

While not an IBM doc, there is an example of this at CBTTAPE.ORG, File 364. It 
is poorly documented, and I can't say if it will work with current z/OS 
releases, but it might be a good start.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: Wednesday, October 2, 2019 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM SSI Function Codes 16 and 17

I'm interested in utilizing SSI Function codes 16 (data set open) and 17 (data 
set close) but I'm not able to find any information on how to use these. In 
looking at the IBM z/OS 2.4 publication on the SSI these are not even included 
in the list of 'allowed' function codes.



Can anyone point me to where I can find out more about how to use these 
function codes in my subsystem?



Thank you





Lionel B. Dyck <
Website:  

 
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.lbdsoftware.com&data=02%7C01%7C%7C6ba9259f2d60401204a408d74757a4af%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637056314064674848&sdata=dX5ze%2BLXSkbyCqATZOdcryMfwUAIcoOvCor1AyZ4fXc%3D&reserved=0

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden




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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Another IBM Mainframe bites the dust

[Schmutzok, Mike (US - Georgia)]

As the systems programmer who saw Shands retire its mainframe, I feel your 
pain.  :o)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Honeycutt,Mary C
Sent: Wednesday, October 02, 2019 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Another IBM Mainframe bites the dust

  ⚠ EXTERNAL MESSAGE – Think Before You Click



Hi All,

After 47 years, The University of Florida, Has shut down our Mainframe.

Thanks,

Cathy Honeycutt

Systems Admin/Programmer III
720 SW 2nd Avenue
Gainesville, FL 32603
flga...@ufl.edu
352 273-1328
MVS - CICS


--
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: multi-line STDPARM shell script for BPXBATCH

[John McKown]

On Wed, Oct 2, 2019 at 1:15 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 2 Oct 2019 11:58:35 -0500, John McKown wrote:
> >>
> >Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!
> >
> Easy enough when you have only one shell command and no comments.
>

You can do multiple shell commands by using the semi-colon "end of command"
character. But you're very correct about no comments. Well, sort of. there
is the "colon" command which is the equivalent of IEFBR14 in batch.

SH cd /tmp2;
   pwd;
   : sort of a comment;
   ls -l;

Will work too. Output from above:

/LIH1/tmp2
total 2
drwxr-x--- 3 AXRUSER  TSHG 288 Oct 13  2016 AXRUSER


-- 
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx

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: multi-line STDPARM shell script for BPXBATCH

[Paul Gilmartin]

On Wed, 2 Oct 2019 11:58:35 -0500, John McKown wrote:
>>
>Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!
> 
Easy enough when you have only one shell command and no comments.

(I didn't know semicolons were optional between awk pattern-action statements.  
YLSED.)

It's a pity that "//DD:DDNAME" isn't supported as an operand of "cp".
Some say it works regardless, just if it breaks you get to keep both pieces.

>//PS001   EXEC PGM=BPXBATCH,REGION=0M
>//*PARM='SH printenv '
>//STDOUT   DD SYSOUT=*
>//STDERR   DD SYSOUT=*
>//STDINDD DUMMY
>//STDPARM  DD *
>SH awk 'BEGIN {count=0;file="";}
>   file != FILENAME && file != ""
>  {print "file " file " has " count " records"}
>   FNR == 1 {file=FILENAME;count=0;}
>   {count++;}
>   END {print "file " file " has " count " records"};
>   '
>"//'sys1.maclib(getmain)'"
>"//'sys1.maclib(read)'" |
>cp /dev/fd/0 "//'tsh009.stdout.txt'"
>/*
>//

-- gil

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

Another IBM Mainframe bites the dust

[Honeycutt,Mary C]

Hi All,

After 47 years, The University of Florida, Has shut down our Mainframe.

Thanks,

Cathy Honeycutt

Systems Admin/Programmer III
720 SW 2nd Avenue
Gainesville, FL 32603
flga...@ufl.edu
352 273-1328
MVS - CICS


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

Re: REXX LISTDSI error

[George, William@FTB]

Sorry, here is Where to subscribe to TSO-REXX

Send your subscribe request to: lists...@vm.marist.edu  
Syntax: SUBscribe   TSO-REXX



-Original Message-
From: George, William@FTB 
Sent: Wednesday, October 02, 2019 9:33 AM
To: 'IBM Mainframe Discussion List' 
Subject: RE: REXX LISTDSI error

There is a TSO-REXX forum that is quite useful. 
tso-r...@vm.marist.edu


__
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole 
use of the intended recipient and may contain confidential and privileged 
information. Any unauthorized review or use, including disclosure or 
distribution, is prohibited. If you are not the intended recipient, please 
contact the sender and destroy all copies of this email.


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

Re: IBM SSI Function Codes 16 and 17

[Charles Mills]

Try older MVS docs. SSI seems to be one of those things where some things
have fallen out of the docs.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lionel B Dyck
Sent: Wednesday, October 2, 2019 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM SSI Function Codes 16 and 17

I'm interested in utilizing SSI Function codes 16 (data set open) and 17
(data set close) but I'm not able to find any information on how to use
these. In looking at the IBM z/OS 2.4 publication on the SSI these are not
even included in the list of 'allowed' function codes.

 

Can anyone point me to where I can find out more about how to use these
function codes in my subsystem?

 

Thank you

 

 

Lionel B. Dyck <
Website:   http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

 


--
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: multi-line STDPARM shell script for BPXBATCH

[John McKown]

On Wed, Oct 2, 2019 at 11:54 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 2 Oct 2019 10:45:39 -0500, Kirk Wolf wrote:
>
> >BPXBATCH still sucks IMO.  It only sucks a bit less than it used to suck.
> >It is probably the most to blame for slow uptake of z/OS Unix.
> >Thankfully, there are much better alternatives.  Some even work the way
> >that you would expect to be able to run z/OS Unix programs / the shell in
> >batch.
> >
> AOPBATCH at least allows instream DD STDIN.  IBM is unlikely to add that
> capability because that would enhance a bundled program to compete
> with a separately charged program.
>
> (I've heard a rumor that AOPBATCH is distributed with base z/OS, but
> can't be used legally without a license.)
>
> Would a SYSEXEC wrapper for BPXWUNIX be useful?  What additional
> features should it have beyond those of BPXBATCH?
>
> -- gil
>
>
Don't use STDIN. Use STDPARM. Example that I use on z/OS 1.12!

//PS001   EXEC PGM=BPXBATCH,REGION=0M
//*PARM='SH printenv '
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//STDINDD DUMMY
//STDPARM  DD *
SH awk 'BEGIN {count=0;file="";}
   file != FILENAME && file != ""
  {print "file " file " has " count " records"}
   FNR == 1 {file=FILENAME;count=0;}
   {count++;}
   END {print "file " file " has " count " records"};
   '
"//'sys1.maclib(getmain)'"
"//'sys1.maclib(read)'" |
cp /dev/fd/0 "//'tsh009.stdout.txt'"
/*
//



-- 
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx

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: multi-line STDPARM shell script for BPXBATCH

[Paul Gilmartin]

On Wed, 2 Oct 2019 10:45:39 -0500, Kirk Wolf wrote:

>BPXBATCH still sucks IMO.  It only sucks a bit less than it used to suck.
>It is probably the most to blame for slow uptake of z/OS Unix.
>Thankfully, there are much better alternatives.  Some even work the way
>that you would expect to be able to run z/OS Unix programs / the shell in
>batch.
> 
AOPBATCH at least allows instream DD STDIN.  IBM is unlikely to add that
capability because that would enhance a bundled program to compete
with a separately charged program.

(I've heard a rumor that AOPBATCH is distributed with base z/OS, but
can't be used legally without a license.)

Would a SYSEXEC wrapper for BPXWUNIX be useful?  What additional
features should it have beyond those of BPXBATCH?

-- gil

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

IBM SSI Function Codes 16 and 17

[Lionel B Dyck]

I'm interested in utilizing SSI Function codes 16 (data set open) and 17
(data set close) but I'm not able to find any information on how to use
these. In looking at the IBM z/OS 2.4 publication on the SSI these are not
even included in the list of 'allowed' function codes.

 

Can anyone point me to where I can find out more about how to use these
function codes in my subsystem?

 

Thank you

 

 

Lionel B. Dyck <
Website:   http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

 


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

Re: REXX LISTDSI error

[George, William@FTB]

There is a TSO-REXX forum that is quite useful. 
tso-r...@vm.marist.edu


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Wednesday, October 02, 2019 8:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX LISTDSI error

Boys, be kind with Bill. He will never learn this way.

ITschak

On Wed, Oct 2, 2019 at 5:48 PM Seymour J Metz  wrote:

> > 'CALL LISTDSI ( dataset.TXT NORECALL)'
>
> What gave you the idea that LISTDSI was a TSO command?
>
> > This keeps returning a RC of -3.
>
> Did you look up what that means? Ignoring other issues, a function is 
> not the same thing as a host command.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Es
> metz3&d=DwIBaQ&c=OH6BQl87xST15P4a0P7x0PHDI-ViE9lGCC1zTisL9ic&r=HPvcl0s
> AG_OLFJIWLUB0E9aO8e9MboKUP0_bmgV0C3w&m=tIG-Ly2UCgxF6MUbHX8aqa-QocQdY0t
> 4bgcTSMt80e8&s=B48ELnPcJpUPTExTMUbIaUpBCsjL5Ii_iQLFTkcKjAY&e=
>
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Bill Giannelli 
> Sent: Wednesday, October 2, 2019 5:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: REXX LISTDSI error
>
> I have the following rexx command:
>
> ADDRESS TSO
> 'CALL LISTDSI ( dataset.TXT NORECALL)'
> ADDRESS TSO
> 'IF SYSREASON = 9  THEN "HDELETE  dataset.TXT WAIT"
> ELSE "DELETE  dataset.TXT"'
>
> This keeps returning a RC of -3.
> processes the rest of the rexx successfully But then leaves the 
> dataset "dataset.txt" as uncataloged.
> Why would it have an uncataloged dataset?
> thanks for any help.
> 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
>


--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for 
Legacy **|  *

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

__
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole 
use of the intended recipient and may contain confidential and privileged 
information. Any unauthorized review or use, including disclosure or 
distribution, is prohibited. If you are not the intended recipient, please 
contact the sender and destroy all copies of this email.


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

AW: Re: deduce program language

[bernd.oppol...@t-online.de]

i would Look if the c Program is Compiled with the Rent Option enabled. If 
so, simply calling at CEESTART will not Work.

Kind regards

Bernd



--- Original-Nachricht ---
Von: Brian Chapman
Betreff: Re: deduce program language
Datum: 02.10.2019, 16:27 Uhr
An: IBM-MAIN@listserv.ua.edu




@font-face { font-family: telegrotesk-medium_normal; src: 
url("file:///android_asset/fonts/telegrotesk_normal.ttf");}html,body { 
font-family: "telegrotesk-medium_normal"; font-size: medium; color: 
#4b4b4b; width: 100%;}

Don,

Thanks for the info. I'm familiar with the LE Vendor Interfaces, but I
guess I need to dig deeper.

With all of my test with COBOL and Assembler have been successful. However,
it always abends when I intercept a C program; usually with the CEE3550
message. Occasionally it is a 0C4 in the intended program.

Does LE have stricter requirements with CEESTART in C programs?


Thank you,

Brian Chapman


On Tue, Oct 1, 2019 at 1:23 PM Don Poitras  wrote:

> In article  t1cmgbfaka497yhff...@mail.gmail.com> you wrote:
> > I created a trace facility to intercept external interface calls (MQ,
> DB2,
> > IMS, etc) and dynamic calls.
> > For dynamic calls, I intercept the load request and replace the entry
> point
> > address with an entry point address of my own program. I then save the
> > original entry point address to later branch to the intended program. 
The
> > interception works for assembler and COBOL programs, but it fails for C
> > programs. When intercepting a C program, the process abends with a 4038
> > (CEE3550S The DLL cannot be loaded because it does not contain a
> CEESTART
> > CSECT).
> > Is there a write-up on how the program load point is mapped and how to
> > deduce the loaded program's language?
> > I hoped to clone my assembler intercept program and create a second 
copy
> > that includes the CEESTART macro to resolve this issue. However, I read
> > that the CEESTART, CEEMAIN, and CEEFMAIN should not be used within an
> > assembler program because it will produce unpredictable behavior. Must 
I
> > write a C program?
> > Thank you,
> > Brian Chapman
>
> I'm not sure how COBOL is working for you as it's an LE program the same
> as C, but perhaps you're not using standard LE DLL's for your COBOL
> programs. CEESTART is not a macro, it's a module/CSECT that gets linked
> from the LE bind library when you compile an LE program or DLL. It's
> always linked as the entry point as that's where the WSA is allocated
> and other housekeeping before the user code is called (either main() or
> the DLL function). LE doc is kind of spread all over the place, but
> for writing an assembler front-end as you're doing, I think the LE
> Vendor Interfaces book is something you should look at.
>
>
> 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ceev100/abstract.htm
>
> --
> Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
> sas...@sas.com (919) 531-5637 Cary, NC 27513
>
> --
> 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





Gesendet mit der Telekom Mail App


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

Re: multi-line STDPARM shell script for BPXBATCH

[Kirk Wolf]

BPXBATCH still sucks IMO.  It only sucks a bit less than it used to suck.
It is probably the most to blame for slow uptake of z/OS Unix.
Thankfully, there are much better alternatives.  Some even work the way
that you would expect to be able to run z/OS Unix programs / the shell in
batch.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Download and use COZBATCH free using our Community License:
https://dovetail.com/docs/cozbatch/intro.html#intro_features

On Tue, Oct 1, 2019 at 11:44 PM Peter Bishop  wrote:

> I love JCL (errrat least I don't hate it quite as much as you).
>
> I guess I'm just used to it and its infrastructure, e.g. automatic SYSOUT
> archiving (admittedly beyond the scope of JCL itself, but based on
> JCL-specified SYSOUT to start with).  Lots of other good options from you
> below for those yet to acquire a taste for it.  I for one am very happy to
> have multi-line STDPARM which greatly increases the utility of BPXBATCH for
> me.  JCL and shell scripts:  best of both worlds if you do it right.
>
> best regards,
> Peter
>
> On Tue, 1 Oct 2019 22:35:35 -0500, Paul Gilmartin 
> wrote:
>
> >On Tue, 1 Oct 2019 22:10:12 -0500, Peter Bishop wrote:
> >
> >>Thanks heaps.
> >>
> >Yaay!  You're welcome.
> >
> >>Firstly, the inline 'no op' which is handy but needs care.
> >>
> >Oops!
> >
> >Other thoughts:
> >
> >BPXWUNIX supports DD:STDIN, DD:STDOUT, and DD:STDERR, for the
> >cost of a trivial Rexx driver.  Then you get true multi-line code in
> >STDIN and comments work.  But the FB80 afflicts you with trailing
> >blanks which interfere with continuation.
> >
> >(You can code such a Rexx driver instream and REPRO it into SYSEXEC,
> >or keep it in a library.)
> >
> >If you're using an editor such as ISPF that lets you insert binary
> >characters in hex, you can code:
> >SET NL='newline'
> >CHANGE 'newline' x'15'
> >... and use STDPARM  SYMBOLS to insert linebreaks.  You need
> >this only once, in a JCLLIB member.  Code the &NL at the front
> >of each STDPARM line rather than the back to avoid leading blanks.
> >
> >I hate JCL!
> >
> >-- gil
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: deduce program language

[Charles Mills]

> Does LE have stricter requirements with CEESTART in C programs?

It might. That's what you are seeing. Or it might just be something about your 
particular C program.

LE is a little bit of a thing of mystery. Despite the "vendor interfaces" book, 
it is not designed such that it is one big generally usable programming 
interface. LE works as a library and so forth for the supported languages, 
generally fairly well. Beyond that you are on your own.

BTW, be sure to test C++ as well. LE C++ is quite different "under the covers" 
from C.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Wednesday, October 2, 2019 7:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: deduce program language

Don,

Thanks for the info. I'm familiar with the LE Vendor Interfaces, but I
guess I need to dig deeper.

With all of my test with COBOL and Assembler have been successful. However,
it always abends when I intercept a C program; usually with the CEE3550
message. Occasionally it is a 0C4 in the intended program.

Does LE have stricter requirements with CEESTART in C programs?

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

Re: REXX LISTDSI error

[ITschak Mugzach]

Boys, be kind with Bill. He will never learn this way.

ITschak

On Wed, Oct 2, 2019 at 5:48 PM Seymour J Metz  wrote:

> > 'CALL LISTDSI ( dataset.TXT NORECALL)'
>
> What gave you the idea that LISTDSI was a TSO command?
>
> > This keeps returning a RC of -3.
>
> Did you look up what that means? Ignoring other issues, a function is not
> the same thing as a host command.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Bill Giannelli 
> Sent: Wednesday, October 2, 2019 5:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: REXX LISTDSI error
>
> I have the following rexx command:
>
> ADDRESS TSO
> 'CALL LISTDSI ( dataset.TXT NORECALL)'
> ADDRESS TSO
> 'IF SYSREASON = 9  THEN "HDELETE  dataset.TXT WAIT"
> ELSE "DELETE  dataset.TXT"'
>
> This keeps returning a RC of -3.
> processes the rest of the rexx successfully
> But then leaves the dataset "dataset.txt" as uncataloged.
> Why would it have an uncataloged dataset?
> thanks for any help.
> 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
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: Tracing RACF?

[retired mainframer]

When the 3.4 list was requested, was a volser specified on the panel?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Sean Gleann
> Sent: Wednesday, October 02, 2019 12:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Tracing RACF?
> 
> Answering 'retired mainframer's questions (and I'll probably be joining you
> within the next year)
> 
>  *What is the status of the SETROPTS PROTECTALL option?*
>  A 'SETROPTS LIST' shows: 'PROTECT-ALL OPTION IS NOT IN EFFECT'. I
> tried switching that with 'setropts protectall(warning)', but the sheer
> volume of output that is generated swamps everything else.
> *Is there any data set profile that covers the dataset?*
>  No - filenames 'TEST' and 'TEST1' (the ones I have been using for
> this) are not specifically identified anywhere in RACF
> *Is there a global access checking table entry that covers the dataset?*
>  Not sure exactly what this means, so I don't know how to check. But
> see previous answer
> *Does the non-admin user have the OPERATIONS attribute?*
>  No.
> *Is there a DASDVOL profile that covers the non-SMS volume in question?*
>  Yes - the DBSYNC output shows 'redefine dasdvol v* uacc(none)',
> followed by 'permit v* class(dasdvol) reset' (and 'v*' covers the volids
> involved).  After that, there are no specific permissions defined
> *And what command is the non-admin user issuing to perform the delete?*
>  Just a simple 'D' against the file in an ISPF 3.4 list.
> 
> Regards
> Sean
> 
> 
> 
> 
> On Tue, 1 Oct 2019 at 16:32, retired mainframer 
> wrote:
> 
> > And what command is the non-admin user issuing to perform the delete?
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of retired mainframer
> > > Sent: Tuesday, October 01, 2019 5:37 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Tracing RACF?
> > >
> > > What is the status of the SETROPTS PROTECTALL option?
> > >
> > > Is there any data set profile that covers the dataset?
> > >
> > > Is there a global access checking table entry that covers the dataset?
> > >
> > > Does the non-admin user have the OPERATIONS attribute?
> > >
> > > Is there a DASDVOL profile that covers the non-SMS volume in question?
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List  On
> > > > Behalf Of Sean Gleann
> > > > Sent: Tuesday, October 01, 2019 3:10 AM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: Tracing RACF?
> > > >
> > > > Joao: yes, I have tried that, but it really doesn't give the
> > information
> > > > that I want - I can see the monitored user creating and deleting file,
> > but
> > > > I don't see anything about the RACF profiles that were used.
> > > >
> > > > Having said that, I have managed to move things along.
> > > > The situation I now have is that an 'ordinary' user of my system(s) -
> > as
> > > > opposed to an 'administrator' user (there are three of us at this
> > site) -
> > > > cannot update the MCAT, so creating files that do not have the user's
> > id as
> > > > the first qualifier is now impossible.
> > > > 'Administrators', on the other hand, can create and delete files at
> > will.
> > > > All of which is OK as far as I'm concerned.
> > > >
> > > > But (there's always a 'but'...)
> > > > If an admin user creates a file named 'TEST' (for instance), the file
> > is
> > > > not covered by my SMS rules, and so it gets placed on one of the 5
> > > > non-SMS-controlled disks that my PARMLIB(VATLSTxx) member identifies as
> > > > being mounted 'PRIVATE'. I'd rather that didn't happen, but we're
> > talking
> > > > about an 'admin'-type user here, and they're supposed to know what
> > they're
> > > > doing, so things are OK up to this point.
> > > > But now it appears that a non-admin user can delete the file, but not
> > > > uncatalog it. The file disappears from the selected disk's VTOC, but
> > the
> > > > MCAT entry remains since the user is not allowed to update the MCAT. If
> > > > this is allowed to continue I'll end up with an MCAT full of orphan
> > entries.
> > > >
> > > > As I say, I've managed to move things along a bit, so my original query
> > > > about 'Tracing RACF' is no longer an issue.
> > > > Right now, I'm trying to improve my system's security so that users can
> > > > create/delete their own files, but cannot do that to anyone else's,
> > nor to
> > > > files that are not covered by SMS.
> > >
> > > --
> > > 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: deduce program language

[Don Poitras]

I've only written LE programs in C and assembler. I would have guessed that 
COBOL had the same requirements for DLLs having the CEESTART entry point,
but it's not something I've looked into. Sorry. Tom Ross can answer if
he sees this. 

In article  
you wrote:
> Don,
> Thanks for the info. I'm familiar with the LE Vendor Interfaces, but I
> guess I need to dig deeper.
> With all of my test with COBOL and Assembler have been successful. However,
> it always abends when I intercept a C program; usually with the CEE3550
> message. Occasionally it is a 0C4 in the intended program.
> Does LE have stricter requirements with CEESTART in C programs?
> Thank you,
> Brian Chapman

> On Tue, Oct 1, 2019 at 1:23 PM Don Poitras  wrote:
> > In article  > t1cmgbfaka497yhff...@mail.gmail.com> you wrote:
> > > I created a trace facility to intercept external interface calls (MQ,
> > DB2,
> > > IMS, etc) and dynamic calls.
> > > For dynamic calls, I intercept the load request and replace the entry
> > point
> > > address with an entry point address of my own program. I then save the
> > > original entry point address to later branch to the intended program. The
> > > interception works for assembler and COBOL programs, but it fails for C
> > > programs. When intercepting a C program, the process abends with a 4038
> > > (CEE3550S  The DLL cannot be loaded because it does not contain a
> > CEESTART
> > > CSECT).
> > > Is there a write-up on how the program load point is mapped and how to
> > > deduce the loaded program's language?
> > > I hoped to clone my assembler intercept program and create a second copy
> > > that includes the CEESTART macro to resolve this issue. However, I read
> > > that the CEESTART, CEEMAIN, and CEEFMAIN should not be used within an
> > > assembler program because it will produce unpredictable behavior. Must I
> > > write a C program?
> > > Thank you,
> > > Brian Chapman
> >
> > I'm not sure how COBOL is working for you as it's an LE program the same
> > as C, but perhaps you're not using standard LE DLL's for your COBOL
> > programs. CEESTART is not a macro, it's a module/CSECT that gets linked
> > from the LE bind library when you compile an LE program or DLL. It's
> > always linked as the entry point as that's where the WSA is allocated
> > and other housekeeping before the user code is called (either main() or
> > the DLL function). LE doc is kind of spread all over the place, but
> > for writing an assembler front-end as you're doing, I think the LE
> > Vendor Interfaces book is something you should look at.
> >
> >
> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ceev100/abstract.htm

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: REXX LISTDSI error

[Seymour J Metz]

> 'CALL LISTDSI ( dataset.TXT NORECALL)' 

What gave you the idea that LISTDSI was a TSO command?

> This keeps returning a RC of -3.

Did you look up what that means? Ignoring other issues, a function is not the 
same thing as a host command.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Bill Giannelli 
Sent: Wednesday, October 2, 2019 5:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: REXX LISTDSI error

I have the following rexx command:

ADDRESS TSO
'CALL LISTDSI ( dataset.TXT NORECALL)'
ADDRESS TSO
'IF SYSREASON = 9  THEN "HDELETE  dataset.TXT WAIT"
ELSE "DELETE  dataset.TXT"'

This keeps returning a RC of -3.
processes the rest of the rexx successfully
But then leaves the dataset "dataset.txt" as uncataloged.
Why would it have an uncataloged dataset?
thanks for any help.
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: deduce program language

[Brian Chapman]

Don,

Thanks for the info. I'm familiar with the LE Vendor Interfaces, but I
guess I need to dig deeper.

With all of my test with COBOL and Assembler have been successful. However,
it always abends when I intercept a C program; usually with the CEE3550
message. Occasionally it is a 0C4 in the intended program.

Does LE have stricter requirements with CEESTART in C programs?


Thank you,

Brian Chapman


On Tue, Oct 1, 2019 at 1:23 PM Don Poitras  wrote:

> In article  t1cmgbfaka497yhff...@mail.gmail.com> you wrote:
> > I created a trace facility to intercept external interface calls (MQ,
> DB2,
> > IMS, etc) and dynamic calls.
> > For dynamic calls, I intercept the load request and replace the entry
> point
> > address with an entry point address of my own program. I then save the
> > original entry point address to later branch to the intended program. The
> > interception works for assembler and COBOL programs, but it fails for C
> > programs. When intercepting a C program, the process abends with a 4038
> > (CEE3550S  The DLL cannot be loaded because it does not contain a
> CEESTART
> > CSECT).
> > Is there a write-up on how the program load point is mapped and how to
> > deduce the loaded program's language?
> > I hoped to clone my assembler intercept program and create a second copy
> > that includes the CEESTART macro to resolve this issue. However, I read
> > that the CEESTART, CEEMAIN, and CEEFMAIN should not be used within an
> > assembler program because it will produce unpredictable behavior. Must I
> > write a C program?
> > Thank you,
> > Brian Chapman
>
> I'm not sure how COBOL is working for you as it's an LE program the same
> as C, but perhaps you're not using standard LE DLL's for your COBOL
> programs. CEESTART is not a macro, it's a module/CSECT that gets linked
> from the LE bind library when you compile an LE program or DLL. It's
> always linked as the entry point as that's where the WSA is allocated
> and other housekeeping before the user code is called (either main() or
> the DLL function). LE doc is kind of spread all over the place, but
> for writing an assembler front-end as you're doing, I think the LE
> Vendor Interfaces book is something you should look at.
>
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ceev100/abstract.htm
>
> --
> Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
> sas...@sas.com   (919) 531-5637Cary, NC 27513
>
> --
> 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: Tracing RACF?

[Robert S. Hansel (RSH)]

Sean,

Deleting datasets from non-SMS managed volumes without dataset access authority 
(assuming the datasets are protected by DATASET profiles to which the users do 
not have ALTER access) may be DASDVOL authorization. See if your users have 
ALTER access to DASDVOL profiles corresponding to your DASD volsers. DASDVOL 
also honors OPERATIONS authority, so ensure the non-admin users don't have this 
authority.

See article "RACF SMF Tidbits" in the July 2016 edition of our RACF Tip 
newsletter.

https://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__July_2016.pdf


Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.twitter.com/RSH_RACF
www.rshconsulting.com

-Original Message-
Date:Tue, 1 Oct 2019 11:10:21 +0100
From:Sean Gleann 
Subject: Re: Tracing RACF?

Joao: yes, I have tried that, but it really doesn't give the information
that I want - I can see the monitored user creating and deleting file, but
I don't see anything about the RACF profiles that were used.

Having said that, I have managed to move things along.
The situation I now have is that an 'ordinary' user of my system(s) - as
opposed to an 'administrator' user (there are three of us at this site) -
cannot update the MCAT, so creating files that do not have the user's id as
the first qualifier is now impossible.
'Administrators', on the other hand, can create and delete files at will.
All of which is OK as far as I'm concerned.

But (there's always a 'but'...)
If an admin user creates a file named 'TEST' (for instance), the file is
not covered by my SMS rules, and so it gets placed on one of the 5
non-SMS-controlled disks that my PARMLIB(VATLSTxx) member identifies as
being mounted 'PRIVATE'. I'd rather that didn't happen, but we're talking
about an 'admin'-type user here, and they're supposed to know what they're
doing, so things are OK up to this point.
But now it appears that a non-admin user can delete the file, but not
uncatalog it. The file disappears from the selected disk's VTOC, but the
MCAT entry remains since the user is not allowed to update the MCAT. If
this is allowed to continue I'll end up with an MCAT full of orphan entries.

As I say, I've managed to move things along a bit, so my original query
about 'Tracing RACF' is no longer an issue.
Right now, I'm trying to improve my system's security so that users can
create/delete their own files, but cannot do that to anyone else's, nor to
files that are not covered by SMS.

Regards
Sean



On Tue, 1 Oct 2019 at 04:24, Jon Perryman  wrote:

>  On Wednesday, September 25, 2019, 07:34:05 AM PDT, Allan Staller <
> allan.stal...@hcl.com> wrote:
>
>  > That is not considered a good practice in RACF circles. The best
> practice would be:
>
> > MCAT  - UACC(NONE) READ(*)  ALTER(sysprogs) (note: No update access
> except via sysprogs)
>
> Any system where the master catalog is not tightly controlled is at great
> risk and could become unusable. Any user can delete any alias in this
> environment. Potentially DB2, CICS, IMS or any number of important aliases
> could be lost.
>
> It's been many years since I've done anything with security. I believe at
> that time, IDCAMS DELETE NOSCRATCH for non-sms datasets was not controlled
> because it was only catalog services and no actual I/O was occurring. Has
> this problem been fixed? If not, then anyone can uncatalog sys1.linklib or
> sys1.lpalib thus causing the IPL to fail.
>
> Why aren't aliases created at the same time as the User? Additionally,
> data is out of control on your system. The RACF admin has not reviewed the
> security implication for aliases.
>
> Jon.
>
> --
> 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: Planned ESQA change and HealthCheck

[Peter Relson]

The choices (most mentioned by one or more posts) for the current IPL are 
among
delete the check (usually a bad choice)
deactivating the check
changing the check parameters
changing the frequency at which the check runs
(many checks support something like this, I did not try to see if the 
check in question does) acknowledging that you have seen the exception so 
that subsequent checks are based on that acknowledged state rather than 
the state from the previous IPL, precisely to avoid reporting on 
situations that you are aware of
starting a new "persistent data" data set (highly discouraged -- that 
history can be valuable just not for the OP's specific case)
And re-IPL will base its new reporting on the previous IPL (which in this 
case will be the larger size).

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: REXX LISTDSI error

[Jeremy Nicoll]

On Wed, 2 Oct 2019, at 10:52, Jeremy Nicoll wrote:

> You need to read a TSO programming manual.  Your code is so full of 
> mistakes that you're going to confuse yourself terribly at this rate.

ALSO...  if you'll pardon me saying so - only an idiot writes code in a 
programming language they don't understand... that's intended to 
delete files.

It'll be a miracle if you don't accidentally delete the wrong ones.

For goodness' sake, learn the language first, then write the utility 
you need.

If you don't have the time to do that, then test the utility with some
final command that isn't as dangerous as DELETE.

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: REXX LISTDSI error

[Jeremy Nicoll]

On Wed, 2 Oct 2019, at 10:32, Bill Giannelli wrote:
> I have the following rexx command:
> 
> ADDRESS TSO   
> 'CALL LISTDSI ( dataset.TXT NORECALL)' 
> ADDRESS TSO   
> 'IF SYSREASON = 9  THEN "HDELETE  dataset.TXT WAIT"
> ELSE "DELETE  dataset.TXT"'   

a) you don't need the second "address tso" because the first one sets
the environment to which all commands will be directed, and you've
not changed it since using it.

b) a better way to use listdsi is by

   lrc = listdsi(thedsn "NORECALL")

where   thedsn   has been given the appropriate value first.   Note that 
the "NORECALL" literal is in quotes, else you risk a variable named 
NORECALL being used instead.  Yes, such a variable if not defined will
default to the same value, but it's better to put literals in quotes.

You need to check the rc from listdsi   (here returned to  lrc)  before you 
look at sysreason.

c) your 'if '  line is not a rexx statement, but instead a command.  You 
  have sent the whole string to TSO.   

You need to read a TSO programming manual.  Your code is so full of 
mistakes that you're going to confuse yourself terribly at this rate.

 
-- 
Jeremy Nicoll - my opinions are my own.

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

Re: EMC DLM Switch failure - Is there a way to set H/W failure alerts?

[Attila Fogarasi]

SNMP is the normal mechanism ... does EMC DLM not support that (hard to
believe), was it misconfigured to not issue the SNMP alert, or are you not
running software to process SNMP and process as appropriate?  This is
pretty standard and not mainframe specific, but there are good mainframe
based SNMP handlers such as from Broadcom (Vantage product).

On Wed, Oct 2, 2019 at 3:08 PM RCG  wrote:

> Hi Experts, Can you please shed some light on setting up H/W alerts on
> Mainframes, We had a situation where one of the two DLM switch failed 2
> weeks ago and before we plan a change to replace that, second one failed as
> well resulting in DLM outage :(
>
> Regards,
>
> --
> 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

REXX LISTDSI error

[Bill Giannelli]

I have the following rexx command:

ADDRESS TSO   
'CALL LISTDSI ( dataset.TXT NORECALL)' 
ADDRESS TSO   
'IF SYSREASON = 9  THEN "HDELETE  dataset.TXT WAIT"
ELSE "DELETE  dataset.TXT"'  

This keeps returning a RC of -3.
processes the rest of the rexx successfully
But then leaves the dataset "dataset.txt" as uncataloged.
Why would it have an uncataloged dataset?
thanks for any help.
Bill  

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

Re: Tracing RACF?

[Sean Gleann]

Answering 'retired mainframer's questions (and I'll probably be joining you
within the next year)

 *What is the status of the SETROPTS PROTECTALL option?*
 A 'SETROPTS LIST' shows: 'PROTECT-ALL OPTION IS NOT IN EFFECT'. I
tried switching that with 'setropts protectall(warning)', but the sheer
volume of output that is generated swamps everything else.
*Is there any data set profile that covers the dataset?*
 No - filenames 'TEST' and 'TEST1' (the ones I have been using for
this) are not specifically identified anywhere in RACF
*Is there a global access checking table entry that covers the dataset?*
 Not sure exactly what this means, so I don't know how to check. But
see previous answer
*Does the non-admin user have the OPERATIONS attribute?*
 No.
*Is there a DASDVOL profile that covers the non-SMS volume in question?*
 Yes - the DBSYNC output shows 'redefine dasdvol v* uacc(none)',
followed by 'permit v* class(dasdvol) reset' (and 'v*' covers the volids
involved).  After that, there are no specific permissions defined
*And what command is the non-admin user issuing to perform the delete?*
 Just a simple 'D' against the file in an ISPF 3.4 list.

Regards
Sean




On Tue, 1 Oct 2019 at 16:32, retired mainframer 
wrote:

> And what command is the non-admin user issuing to perform the delete?
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of retired mainframer
> > Sent: Tuesday, October 01, 2019 5:37 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Tracing RACF?
> >
> > What is the status of the SETROPTS PROTECTALL option?
> >
> > Is there any data set profile that covers the dataset?
> >
> > Is there a global access checking table entry that covers the dataset?
> >
> > Does the non-admin user have the OPERATIONS attribute?
> >
> > Is there a DASDVOL profile that covers the non-SMS volume in question?
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Sean Gleann
> > > Sent: Tuesday, October 01, 2019 3:10 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Tracing RACF?
> > >
> > > Joao: yes, I have tried that, but it really doesn't give the
> information
> > > that I want - I can see the monitored user creating and deleting file,
> but
> > > I don't see anything about the RACF profiles that were used.
> > >
> > > Having said that, I have managed to move things along.
> > > The situation I now have is that an 'ordinary' user of my system(s) -
> as
> > > opposed to an 'administrator' user (there are three of us at this
> site) -
> > > cannot update the MCAT, so creating files that do not have the user's
> id as
> > > the first qualifier is now impossible.
> > > 'Administrators', on the other hand, can create and delete files at
> will.
> > > All of which is OK as far as I'm concerned.
> > >
> > > But (there's always a 'but'...)
> > > If an admin user creates a file named 'TEST' (for instance), the file
> is
> > > not covered by my SMS rules, and so it gets placed on one of the 5
> > > non-SMS-controlled disks that my PARMLIB(VATLSTxx) member identifies as
> > > being mounted 'PRIVATE'. I'd rather that didn't happen, but we're
> talking
> > > about an 'admin'-type user here, and they're supposed to know what
> they're
> > > doing, so things are OK up to this point.
> > > But now it appears that a non-admin user can delete the file, but not
> > > uncatalog it. The file disappears from the selected disk's VTOC, but
> the
> > > MCAT entry remains since the user is not allowed to update the MCAT. If
> > > this is allowed to continue I'll end up with an MCAT full of orphan
> entries.
> > >
> > > As I say, I've managed to move things along a bit, so my original query
> > > about 'Tracing RACF' is no longer an issue.
> > > Right now, I'm trying to improve my system's security so that users can
> > > create/delete their own files, but cannot do that to anyone else's,
> nor to
> > > files that are not covered by SMS.
> >
> > --
> > 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