Re: AXR address space

2017-08-18 Thread Lucas Rosalen
We use 2 methods at the same time with System Automation:
- INGLKUP REQ=JOB COMMAND=STOP to perform a P AXRxx,A=
- P AXR

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2017-08-18 18:55 GMT+02:00 Gilson Cesar de Oliveira :

>
> Dear list:
>
> I'd like to know how to stop the AXR address space without using the
> CANCEL command??
>
> I already tried with STOP but it didn't work.
>
> Any clues??
>
>
> Thanks in advance for any help.
>
> 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: GSKSRVR trace

2017-08-18 Thread Schmutzok, Mike (Alpharetta)
I think you have to start the GSKSRVR first before starting the GSK writer. We 
had to do an SSL trace per IBM's request and the following was the process they 
gave to us. Note, this was for a CICS trace so your reply may be different.


1) Start the GSKSRVR started task:  
   S GSKSRVR
2) Start the trace writer proc with the console command:
   TRACE CT,WTRSTART=GSKWTR 
3) Start SSL CTRACE with the console command:   
   TRACE CT,ON,COMP=GSKSRVR 
4) Reply to the outstanding reply: (yourjob is the name of the CICS 
region to be traced)
   R xx,JOBNAME=(yourjob),OPTIONS=(LEVEL=255),WTR=GSKWTR,END
4a) D TRACE,COMP=GSKSRVR,SUB=(jobname)  to verify trace is active   
4b) Refresh the SSL environment using CEMT PERFORM SSL REBUILD  
5) Establish a connection to CICS   
6) Stop SSL CTRACE with the console command:
   TRACE CT,OFF,COMP=GSKSRVR
7) Stop the trace writer proc with the console command: 
   TRACE CT,WTRSTOP=GSKWTR,FLUSH
8) Stop the GSKSRVR started task:   
   P GSKSRVR   



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Smith III, Phil (HPE Data Security (Voltage))
Sent: Friday, August 18, 2017 6:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: GSKSRVR trace

Ok, I'm hopelessly ignorant about z/OS tracing, so please don't laugh (too 
hard).

I'm trying to follow the instructions on 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.gska100/sssl2dia1023728.htm
 to learn about SSL tracing. Yes, this is a test system.

I copied the GSK.SGSKSAMP(GSKWTR) member to the PROCLIB and customized it:
//GSKWTR   PROC
//IEFPROC  EXEC  PGM=ITTTRCWR,REGION=32M
//TRCOUT01  DD   DSN=PHS.GSK.TRACE1,DISP=(NEW,CATLG),
//SPACE=(CYL,(10)),UNIT=SYSDA

Then I issued:
TRACE CT,WTRSTART=GSKWTR

which got:
ITT038I ALL OF THE TRANSACTIONS REQUESTED VIA THE TRACE CT COMMAND WERE 
SUCCESSFULLY EXECUTED.
IEE839I ST=(ON,0001M,4M) AS=ON  BR=OFF EX=ON  MO=OFF MT=(ON,064K)
451
ISSUE DISPLAY TRACE CMD FOR SYSTEM AND COMPONENT TRACE STATUS
ISSUE DISPLAY TRACE,TT CMD FOR TRANSACTION TRACE STATUS
IEF196I 1 //GSKWTR   JOB MSGLEVEL=1
IEF196I 2 //STARTING EXEC GSKWTR
IEF196I  STMT NO. MESSAGE
IEF196I 2 IEFC001I PROCEDURE GSKWTR WAS EXPANDED USING SYSTEM
IEF196I LIBRARY VENDOR.PROCLIB
IEF196I 3 XXGSKWTR   PROC
IEF196I 4 XXIEFPROC  EXEC  PGM=ITTTRCWR,REGION=32M
IEF196I 5 XXTRCOUT01  DD   DSN=PHS.GSK.TRACE1,DISP=(NEW,CATLG),
IEF196I   XXSPACE=(CYL,(10)),UNIT=SYSDA
IEF196I IEF236I ALLOC. FOR GSKWTR GSKWTR
IEF196I IGD100I 0D39 ALLOCATED TO DDNAME TRCOUT01 DATACLAS ()
IEF196I AHL906I THE OUTPUT BLOCK SIZE OF27998 WILL BE USED FOR
IEF196I OUTPUT
IEF196I DATA SETS:
IEF196I   PHS.GSK.TRACE1
AHL906I THE OUTPUT BLOCK SIZE OF27998 WILL BE USED FOR OUTPUT 463
DATA SETS:
  PHS.GSK.TRACE1
ITT110I INITIALIZATION OF CTRACE WRITER GSKWTR COMPLETE.

So far so good. Then I issue:
TRACE CT,ON,COMP=GSKSRVR
and I get:
ITT001I TRACE COMP=GSKSRVR 472
IS NOT DEFINED.
ITT038I NONE OF THE TRANSACTIONS REQUESTED VIA THE TRACE CT COMMAND WERE  
SUCCESSFULLY EXECUTED.
IEE839I ST=(ON,0001M,4M) AS=ON  BR=OFF EX=ON  MO=OFF MT=(ON,064K)
474
ISSUE DISPLAY TRACE CMD FOR SYSTEM AND COMPONENT TRACE STATUS
ISSUE DISPLAY TRACE,TT CMD FOR TRANSACTION TRACE STATUS

OK, I'm missing something basic (and probably obvious). Any idea what?

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


GSKSRVR trace

2017-08-18 Thread Smith III, Phil (HPE Data Security (Voltage))
Ok, I'm hopelessly ignorant about z/OS tracing, so please don't laugh (too 
hard).

I'm trying to follow the instructions on 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.gska100/sssl2dia1023728.htm
 to learn about SSL tracing. Yes, this is a test system.

I copied the GSK.SGSKSAMP(GSKWTR) member to the PROCLIB and customized it:
//GSKWTR   PROC
//IEFPROC  EXEC  PGM=ITTTRCWR,REGION=32M
//TRCOUT01  DD   DSN=PHS.GSK.TRACE1,DISP=(NEW,CATLG),
//SPACE=(CYL,(10)),UNIT=SYSDA

Then I issued:
TRACE CT,WTRSTART=GSKWTR

which got:
ITT038I ALL OF THE TRANSACTIONS REQUESTED VIA THE TRACE CT COMMAND WERE
SUCCESSFULLY EXECUTED.
IEE839I ST=(ON,0001M,4M) AS=ON  BR=OFF EX=ON  MO=OFF MT=(ON,064K)
451
ISSUE DISPLAY TRACE CMD FOR SYSTEM AND COMPONENT TRACE STATUS
ISSUE DISPLAY TRACE,TT CMD FOR TRANSACTION TRACE STATUS
IEF196I 1 //GSKWTR   JOB MSGLEVEL=1
IEF196I 2 //STARTING EXEC GSKWTR
IEF196I  STMT NO. MESSAGE
IEF196I 2 IEFC001I PROCEDURE GSKWTR WAS EXPANDED USING SYSTEM
IEF196I LIBRARY VENDOR.PROCLIB
IEF196I 3 XXGSKWTR   PROC
IEF196I 4 XXIEFPROC  EXEC  PGM=ITTTRCWR,REGION=32M
IEF196I 5 XXTRCOUT01  DD   DSN=PHS.GSK.TRACE1,DISP=(NEW,CATLG),
IEF196I   XXSPACE=(CYL,(10)),UNIT=SYSDA
IEF196I IEF236I ALLOC. FOR GSKWTR GSKWTR
IEF196I IGD100I 0D39 ALLOCATED TO DDNAME TRCOUT01 DATACLAS ()
IEF196I AHL906I THE OUTPUT BLOCK SIZE OF27998 WILL BE USED FOR
IEF196I OUTPUT
IEF196I DATA SETS:
IEF196I   PHS.GSK.TRACE1
AHL906I THE OUTPUT BLOCK SIZE OF27998 WILL BE USED FOR OUTPUT 463
DATA SETS:
  PHS.GSK.TRACE1
ITT110I INITIALIZATION OF CTRACE WRITER GSKWTR COMPLETE.

So far so good. Then I issue:
TRACE CT,ON,COMP=GSKSRVR
and I get:
ITT001I TRACE COMP=GSKSRVR 472
IS NOT DEFINED.
ITT038I NONE OF THE TRANSACTIONS REQUESTED VIA THE TRACE CT COMMAND WERE
 SUCCESSFULLY EXECUTED.
IEE839I ST=(ON,0001M,4M) AS=ON  BR=OFF EX=ON  MO=OFF MT=(ON,064K)
474
ISSUE DISPLAY TRACE CMD FOR SYSTEM AND COMPONENT TRACE STATUS
ISSUE DISPLAY TRACE,TT CMD FOR TRANSACTION TRACE STATUS

OK, I'm missing something basic (and probably obvious). Any idea what?

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


Re: IBM Session Manager replacement

2017-08-18 Thread Crispin Hugo
There is one product that does exactly the same from Macro4 as they wrote and 
support The IBM session manager. 

Crispin Hugo
Systems Specialist
Macro 4 Limited
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | www.macro4.com

      

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Longnecker, Dennis
Sent: 18 August 2017 17:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM Session Manager replacement

Good luck on this.  Every few years I look at what is out there to replace TPX. 
 TPX is a great multi-session product and does what we need it to do, but when 
I  get the about $60,000 bill every year I wonder what else is out there.

TPX ties in with RACF pretty well and it dynamically builds the persons "menu" 
when they signon based on their RACF profiles.  Love this capability because we 
never have to do TPX administration.  Just add the user to RACF and it all 
happens dynamically.  Some of the other products do this also.

TPX also lets you "view" a person's screen.  This is a wonderful feature the 
help desk uses.  When a customer calls in with a problem, the person just 
enters the RACFID of the person and they can see what they are doing real-time 
without the caller having to do anything. 

The main reason we still have TPX is SMF records.  TPX does an excellent job of 
writing out SMF data on all sorts of activity.  In particular we can see how 
many transactions a user did in total and per session they signon to.  We use 
this information a lot and have many reports for managers to view activity.

Good luck on your endeavor.

Dennis




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roberto Halais
Sent: Thursday, August 17, 2017 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM Session Manager replacement

Hi listers:

IBM has notified that IBM Session Manager product will be phased out by the end 
of 2018.

They suggest we migrate to IBM CL/Supersession.

I would like to know of other vendor products that do a similar function.

I will be searching but thought of tapping into your experience.

Thank you all for any hints.

Roberto

--
Politics: Poli (many) - tics (blood sucking parasites)

--
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 e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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


Re: IBM Session Manager replacement

2017-08-18 Thread Pew, Curtis G
On Aug 18, 2017, at 12:09 PM, Wendell Lovewell  wrote:
> 
> MacKinney Systems as VTAM/Switch.

We’ve been using this for years, and are quite happy with it.

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


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


Re: IBM Session Manager replacement

2017-08-18 Thread Wendell Lovewell

MacKinney Systems as VTAM/Switch.  We'll help you with converting your session 
manager definitions, and more than a couple of you could license it for $60k a 
year! 

(Dennis, give us a call!)


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


AXR address space

2017-08-18 Thread Gilson Cesar de Oliveira

Dear list:

I'd like to know how to stop the AXR address space without using the CANCEL 
command??

I already tried with STOP but it didn't work.

Any clues??


Thanks in advance for any help.

Regards,

Gilson

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


Re: simple questions on migrating to a new mastercat

2017-08-18 Thread Chris Hoelscher
Manualus  interruptus ?

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services

123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Friday, August 18, 2017 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] simple questions on migrating to a new mastercat

Please don't interrupt the manuals, they don't like that.  :-D

TGIF!

sas

On Fri, Aug 18, 2017 at 11:27 AM, Tracy Adams  wrote:
> Thanks Tom, the way I first interrupted the manual was incorrect... you can 
> use recatalog and catalog in the same define command and get the desired 
> results (an entry in the second mastcat that include the SMS attributes).
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tom Marchant
> Sent: Thursday, August 17, 2017 4:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: simple questions on migrating to a new mastercat
>
> On Thu, 17 Aug 2017 20:23:25 +, Tracy Adams wrote:
>
>>So I am built a new master catalog for the 2.2 migration.
>>I have some sys1. Datasets that live on various sms volumes
>>that I want add catalog entries to in my new mastcat.   If I
>>just use IDCAMS define nonvsam I get a good entry but there is no SMS 
>>information.
>>I can't use "recatalog" because the catalog names are different.
>
> Yes you can, for SYS1. data sets. See the IDCAMS manual.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
sas

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability or
sex. Humana Inc. and its subsidiaries do not exclude people or treat them 
differently
because of race, color, national origin, age, disability or sex.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


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


Re: IBM Session Manager replacement

2017-08-18 Thread Longnecker, Dennis
Good luck on this.  Every few years I look at what is out there to replace TPX. 
 TPX is a great multi-session product and does what we need it to do, but when 
I  get the about $60,000 bill every year I wonder what else is out there.

TPX ties in with RACF pretty well and it dynamically builds the persons "menu" 
when they signon based on their RACF profiles.  Love this capability because we 
never have to do TPX administration.  Just add the user to RACF and it all 
happens dynamically.  Some of the other products do this also.

TPX also lets you "view" a person's screen.  This is a wonderful feature the 
help desk uses.  When a customer calls in with a problem, the person just 
enters the RACFID of the person and they can see what they are doing real-time 
without the caller having to do anything. 

The main reason we still have TPX is SMF records.  TPX does an excellent job of 
writing out SMF data on all sorts of activity.  In particular we can see how 
many transactions a user did in total and per session they signon to.  We use 
this information a lot and have many reports for managers to view activity.

Good luck on your endeavor.

Dennis




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roberto Halais
Sent: Thursday, August 17, 2017 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM Session Manager replacement

Hi listers:

IBM has notified that IBM Session Manager product will be phased out by the end 
of 2018.

They suggest we migrate to IBM CL/Supersession.

I would like to know of other vendor products that do a similar function.

I will be searching but thought of tapping into your experience.

Thank you all for any hints.

Roberto

--
Politics: Poli (many) - tics (blood sucking parasites)

--
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: Removing Catalog Entries for Datasets That Do Not Exist

2017-08-18 Thread Allan Staller
As others have said, DEL 'dsname' NSCR will fix you up.

However, I am aware of at least one other product that also uses this 
convention.
Be careful!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Friday, August 18, 2017 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Removing Catalog Entries for Datasets That Do Not Exist

Hello Everyone,

Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.

When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.

Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.

Thank you.

Bill

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.



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


Re: simple questions on migrating to a new mastercat

2017-08-18 Thread Steve Smith
Please don't interrupt the manuals, they don't like that.  :-D

TGIF!

sas

On Fri, Aug 18, 2017 at 11:27 AM, Tracy Adams  wrote:
> Thanks Tom, the way I first interrupted the manual was incorrect... you can 
> use recatalog and catalog in the same define command and get the desired 
> results (an entry in the second mastcat that include the SMS attributes).
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Tom Marchant
> Sent: Thursday, August 17, 2017 4:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: simple questions on migrating to a new mastercat
>
> On Thu, 17 Aug 2017 20:23:25 +, Tracy Adams wrote:
>
>>So I am built a new master catalog for the 2.2 migration.
>>I have some sys1. Datasets that live on various sms volumes
>>that I want add catalog entries to in my new mastcat.   If I
>>just use IDCAMS define nonvsam I get a good entry but there is no SMS
>>information.
>>I can't use "recatalog" because the catalog names are different.
>
> Yes you can, for SYS1. data sets. See the IDCAMS manual.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
sas

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


Re: Removing Catalog Entries for Datasets That Do Not Exist [Public Information]

2017-08-18 Thread Longabaugh, Robert E
If you are not running DFHSM are you running any other product that could cause 
MIGRAT entries?   When CA Disk archives data sets, they are recataloged to 
MIGRAT with DEVT(C4C9E2D2).  In that case the catalog entry is legitimate.

Bob Longabaugh
CA Technologies 
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Usher, Darrold
Sent: Friday, August 18, 2017 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Removing Catalog Entries for Datasets That Do Not Exist [Public 
Information]

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


Did your try DEL 'dsname' NSCR?

Classification: Public Information


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Friday, August 18, 2017 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Removing Catalog Entries for Datasets That Do Not Exist

Hello Everyone,

Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.

When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.

Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.

Thank you.

Bill

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

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

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


Re: IBM Session Manager replacement

2017-08-18 Thread Roberto Halais
Thank you Ed. Good info to know.


On Fri, Aug 18, 2017 at 11:43 AM Ed Jaffe 
wrote:

> On 8/17/2017 3:20 PM, Roberto Halais wrote:
> > IBM has notified that IBM Session Manager product will be phased out by
> the
> > end of 2018.
> >
> > They suggest we migrate to IBM CL/Supersession.
> >
> > I would like to know of other vendor products that do a similar function.
>
> IBM Session Manager for z/OS is Macro 4 Tubes (rebranded). So, if you
> want near-zero conversion effort, that would be the way to go.
>
> CL/Supersession isn't a bad product (originally from Candle), but who's
> doing the development now?
>
> IBM disbanded their product development teams for SDSF, the entire
> OMEGAMON suite (also originally from Candle), the entire Optim suite,
> File Manager, Fault Analyzer, Tivoli Workload Scheduler (and related
> products), Security AppScan, Transformation Extender,  a bunch of
> Rational products (Synergy & Change, Test Automation, BuildForge, Asset
> Manager, etc.) and so many others it's hard to keep up any more. These
> products are now partnership owned and developed by ISVs under
> intellectual property and profit sharing arrangements. I suspect the
> same is true of CL/Supersession. I just don't know who really owns and
> develops it. If anyone knows for sure, please post to the list...
>
> --
> PHOENIX SOFTWARE INTERNATIONAL
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Politics: Poli (many) - tics (blood sucking parasites)

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


Re: Removing Catalog Entries for Datasets That Do Not Exist [Public Information]

2017-08-18 Thread Usher, Darrold
Did your try DEL 'dsname' NSCR?

Classification: Public Information


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Friday, August 18, 2017 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Removing Catalog Entries for Datasets That Do Not Exist

Hello Everyone,

Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.

When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.

Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.

Thank you.

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: Testing zOS 2.3 ?

2017-08-18 Thread Richards, Robert B.
Ed,

Speaking of SHARE presentations.  :-)

Does anyone know when will they be made available?

Thanks for attaching yours. Very informative.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Thursday, August 17, 2017 6:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Testing zOS 2.3 ?

On 8/9/2017 11:05 PM, Peter wrote:
> Is anyone performing any kind of testing on zOS 2.3 and found any 
> defects or any gotchas ?

https://share.confex.com/data/handout/share/129/Session_21586_handout_10845_0.pdf

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
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: Removing Catalog Entries for Datasets That Do Not Exist

2017-08-18 Thread Burrell, Todd
Wouldn't a simple IDCAMS DELETE NSCR work?  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rodatz, William J
Sent: Friday, August 18, 2017 11:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Removing Catalog Entries for Datasets That Do Not Exist

Hello Everyone,

Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.

When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.

Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.

Thank you.

Bill

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



This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.

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


Removing Catalog Entries for Datasets That Do Not Exist

2017-08-18 Thread Rodatz, William J
Hello Everyone,

Recently I discovered some datasets with "MIGRAT" as the volser.  These 
datasets had been migrated with DFHSM many years ago.  My organization is no 
longer running the product.  I am attempting to remove the dangling catalog 
entries which appears to be challenging.  The pubs say to use IEHPROGM with the 
SCRATCH function if (1) the dataset is non-SMS managed and (2) you know the 
dataset's volser prior to migration.  I don't what the original volser was and 
I don't know why it matters.  The catalog entry has only the dataset name and 
"MIGRAT" for the volser.

When I execute IEHPROGM, I get messages denoting that DFHSM is not active.  I 
am unable to move past this point.

Does anyone have an idea how the catalog entries can be removed?  Any input 
would be greatly appreciated.

Thank you.

Bill

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


Re: Possible COBOL RFE to abend if any warnings occured

2017-08-18 Thread Frank Swarbrick
I never said anything about production.  This would be (in our environment, 
anyway) set automatically for any development compiles only.


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Friday, August 18, 2017 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Possible COBOL RFE to abend if any warnings occured

I agree with Jeffrey's comment and will add one of my own:  No program should 
be installed into QA or UAT or production libraries with SSRANGE or ZONECHECK 
or any other debugging option turned on at all.  There should be lifecycle 
software rules in place to automatically prevent it from ever happening.

Debugging options are for debugging problems and for unit and regression 
testing, never for production.  You are costing yourself serious CPU usage to 
leave them turned on in production.  When a programmer is debugging or changing 
code they should already know enough to look at the message output (batch or 
CICS) when they have debugging compiler options turned on.  If they don't know 
that then they don't deserve the label "programmer".

Like the old vaudeville routine said, "Patient: Doctor!  Doctor!  It hurts when 
I do that!"  "Doctor: Well, don't do that!"

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jeffrey Holst
Sent: Friday, August 18, 2017 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Possible COBOL RFE to abend if any warnings occured

Unless you have other specific examples, both NUMCHECK and SSRANGE already 
offer the ABD sub-option. I would think the RFE would be rejected as already 
delivered.

On Fri, 18 Aug 2017 00:19:14 +, Frank Swarbrick 
 wrote:

>Not yet submitted.  Please comment.
>
>COBOL Language Environment �warning� messages (severity code 1) are written to 
>the destination supplied by the MSGFILE runtime option.  This defaults to 
>CEEMSG for batch jobs and the CESE TD queue for CICS (where CESE is generally 
>mapped to the CEEMSG DD�)
>
>There is nothing about the execution of a program currently that will give any 
>indication that any warning conditions occurred, other than the existence of 
>these messages.  So if you want to know if a particular execution of a program 
>caused any warning conditions you must look at the appropriate output.
>
>Enterprise COBOL has recently added new compile options with sub-options ABD 
>and MSG.  When ABD is specified the program will, when certain conditions 
>occur, raise a severity 2 LE condition, which in turn (if not �handled�) will 
>cause the program to abend with code U4038 (or return code 3000 when runtime 
>option ABTERMENC(RETURN) in used instead of the default ABTERMENC(ABEND).
>
>When MSG is specified then only a severity 1 LE condition is raised.  This 
>causes COBOL to simply write the message and then continue on to the next 
>COBOL statement.
>
>Unless you are specifically thinking that your program run might have warnings 
>you may not check for them.  This is especially true for a CICS transaction, 
>since there is generally no �batch output� to review.
>
>It could be useful to have a run-time condition that optionally would be 
>raised at the termination of the run-unit (via STOP RUN or a GOBACK of the 
>�initial� program) if any COBOL warning condition was raised within the 
>run-unit.  This new condition should be at least a level 2 condition so that 
>it will in turn cause the existing CEE0198S condition to be raised if it is 
>not suppressed by a condition handler or other method, which in turn would 
>cause the U4038 abend.
>
>Use case:
>COBOL program is compiled with SSRANGE(MSG) and NUMCHECK(MSG).  When a 
>condition is raised as a result of something these options check for it causes 
>an appropriate warning message to be written to the LE MSGFILE.  As part of 
>COBOL run-unit termination it should check to see if any SEV 1 conditions 
>caused warning messages to be written.  If so it should raise a new SEV 2 (or 
>above) condition.
>
>Considerations:
>-Can/should this be done such that the current unit of work is committed 
>prior to the abend occurring?
>-Use of this feature might necessitate the ability to suppress warning 
>messages that are expected.  This would probably have to be done at compile 
>time.  Perhaps a new �compiler directive� statement could be used to 
>�surround� code that causes a warning condition to occur but where you want to 
>suppress the warning.
>
>Other discussion:
>I thought that I might be able to code this myself as a condition handler 
>which I would then specify as the second parameter to the USRHDLR run-time 
>option.  I could not get this to work, because it appears that you cannot 
>�promote� the CEE0199W condition to another condition.
>
>Additionally, if you end your run-unit via a GOBACK instead of a STOP RUN it 
>does not 

Re: IBM Session Manager replacement

2017-08-18 Thread Ed Jaffe

On 8/17/2017 3:20 PM, Roberto Halais wrote:

IBM has notified that IBM Session Manager product will be phased out by the
end of 2018.

They suggest we migrate to IBM CL/Supersession.

I would like to know of other vendor products that do a similar function.


IBM Session Manager for z/OS is Macro 4 Tubes (rebranded). So, if you 
want near-zero conversion effort, that would be the way to go.


CL/Supersession isn't a bad product (originally from Candle), but who's 
doing the development now?


IBM disbanded their product development teams for SDSF, the entire 
OMEGAMON suite (also originally from Candle), the entire Optim suite, 
File Manager, Fault Analyzer, Tivoli Workload Scheduler (and related 
products), Security AppScan, Transformation Extender,  a bunch of 
Rational products (Synergy & Change, Test Automation, BuildForge, Asset 
Manager, etc.) and so many others it's hard to keep up any more. These 
products are now partnership owned and developed by ISVs under 
intellectual property and profit sharing arrangements. I suspect the 
same is true of CL/Supersession. I just don't know who really owns and 
develops it. If anyone knows for sure, please post to the list...


--
PHOENIX SOFTWARE INTERNATIONAL
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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


Re: Possible COBOL RFE to abend if any warnings occured

2017-08-18 Thread Frank Swarbrick
They do, but the point of the MSG option as it exists today is to "change 
SSRANGE [etc.] checking to issue a non-terminating, warning-level runtime 
message which in turn allow COBOL to report on all subscript or index 
out-of-range conditions, in a single run of the application." (quoted from 
http://www-01.ibm.com/support/docview.wss?uid=swg1PI74933).  Note the "in a 
single run of the application."  The point of my RFE would be so that the user 
could know that any warnings actually occurred.  If someone has a better idea I 
am open to suggestions.


From: IBM Mainframe Discussion List  on behalf of 
Jeffrey Holst 
Sent: Friday, August 18, 2017 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Possible COBOL RFE to abend if any warnings occured

Unless you have other specific examples, both NUMCHECK and SSRANGE already 
offer the ABD sub-option. I would think the RFE would be rejected as already 
delivered.

On Fri, 18 Aug 2017 00:19:14 +, Frank Swarbrick 
 wrote:

>Not yet submitted.  Please comment.
>
>COBOL Language Environment �warning� messages (severity code 1) are written to 
>the destination supplied by the MSGFILE runtime option.  This defaults to 
>CEEMSG for batch jobs and the CESE TD queue for CICS (where CESE is generally 
>mapped to the CEEMSG DD�)
>
>There is nothing about the execution of a program currently that will give any 
>indication that any warning conditions occurred, other than the existence of 
>these messages.  So if you want to know if a particular execution of a program 
>caused any warning conditions you must look at the appropriate output.
>
>Enterprise COBOL has recently added new compile options with sub-options ABD 
>and MSG.  When ABD is specified the program will, when certain conditions 
>occur, raise a severity 2 LE condition, which in turn (if not �handled�) will 
>cause the program to abend with code U4038 (or return code 3000 when runtime 
>option ABTERMENC(RETURN) in used instead of the default ABTERMENC(ABEND).
>
>When MSG is specified then only a severity 1 LE condition is raised.  This 
>causes COBOL to simply write the message and then continue on to the next 
>COBOL statement.
>
>Unless you are specifically thinking that your program run might have warnings 
>you may not check for them.  This is especially true for a CICS transaction, 
>since there is generally no �batch output� to review.
>
>It could be useful to have a run-time condition that optionally would be 
>raised at the termination of the run-unit (via STOP RUN or a GOBACK of the 
>�initial� program) if any COBOL warning condition was raised within the 
>run-unit.  This new condition should be at least a level 2 condition so that 
>it will in turn cause the existing CEE0198S condition to be raised if it is 
>not suppressed by a condition handler or other method, which in turn would 
>cause the U4038 abend.
>
>Use case:
>COBOL program is compiled with SSRANGE(MSG) and NUMCHECK(MSG).  When a 
>condition is raised as a result of something these options check for it causes 
>an appropriate warning message to be written to the LE MSGFILE.  As part of 
>COBOL run-unit termination it should check to see if any SEV 1 conditions 
>caused warning messages to be written.  If so it should raise a new SEV 2 (or 
>above) condition.
>
>Considerations:
>-Can/should this be done such that the current unit of work is committed 
>prior to the abend occurring?
>-Use of this feature might necessitate the ability to suppress warning 
>messages that are expected.  This would probably have to be done at compile 
>time.  Perhaps a new �compiler directive� statement could be used to 
>�surround� code that causes a warning condition to occur but where you want to 
>suppress the warning.
>
>Other discussion:
>I thought that I might be able to code this myself as a condition handler 
>which I would then specify as the second parameter to the USRHDLR run-time 
>option.  I could not get this to work, because it appears that you cannot 
>�promote� the CEE0199W condition to another condition.
>
>Additionally, if you end your run-unit via a GOBACK instead of a STOP RUN it 
>does not cause any condition to occur, and thus the handler is not invoked at 
>run-unit termination.  So there would be no way to cause a new condition via 
>the handler in this case.
>Frank
>
>--
>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,

Re: IBM Session Manager replacement

2017-08-18 Thread Stone, Marshall
FYI - We are currently running NVAS and will migrate to CL/SS in 2018 - We 
contracted IBM to assist, they have REXX code/Processes to copy/clone NVAS 
customization to CL/SS to ease migrations for shops with heavily customized 
screens and scripts.

MS
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roberto Halais
Sent: Friday, August 18, 2017 10:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: IBM Session Manager replacement

Thank you all for your responses these will help inmensely.
Again. Thank you
Roberto


On Aug 18, 2017 8:36 AM, "Wolfgang Fritz" < 
016acdc52809-dmarc-requ...@listserv.ua.edu> wrote:

> Hi
> I forgot to give you a URL
>
> www.virtelweb.com
>
>
> You could download and test it for
> 5 users
>
> If you need support
> You can send me a mail wolfgang.fr...@wfs-gmbh.eu
>
>
>
> Bin unterwegs hab nur iPhone zur Verfügung.
>
> > Am 18.08.2017 um 14:08 schrieb william janulin
> > <008d52e04f2e-dmarc-
> requ...@listserv.ua.edu>:
> >
> > There is also TUBES from Macro 4.
> >
> >
> >On Friday, August 18, 2017 7:53 AM, Wolfgang Fritz <
> 016acdc52809-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >
> > Hi
> > There is another possibility try
> > Syspertec Virtel there is a Session manager Included and you could
> > earn your 3270 emulation you work only browser
> based with a http/SNA gateway
> > RegArds
> > Wolfgang
> > 
> > -- 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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only. Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited. If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

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


Re: simple questions on migrating to a new mastercat

2017-08-18 Thread Tracy Adams
Thanks Tom, the way I first interrupted the manual was incorrect... you can use 
recatalog and catalog in the same define command and get the desired results 
(an entry in the second mastcat that include the SMS attributes).

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, August 17, 2017 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: simple questions on migrating to a new mastercat

On Thu, 17 Aug 2017 20:23:25 +, Tracy Adams wrote:

>So I am built a new master catalog for the 2.2 migration.
>I have some sys1. Datasets that live on various sms volumes 
>that I want add catalog entries to in my new mastcat.   If I 
>just use IDCAMS define nonvsam I get a good entry but there is no SMS 
>information.
>I can't use "recatalog" because the catalog names are different.

Yes you can, for SYS1. data sets. See the IDCAMS manual.

--
Tom Marchant

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

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


Re: IBM Session Manager replacement

2017-08-18 Thread Roberto Halais
Thank you all for your responses these will help inmensely.
Again. Thank you
Roberto


On Aug 18, 2017 8:36 AM, "Wolfgang Fritz" <
016acdc52809-dmarc-requ...@listserv.ua.edu> wrote:

> Hi
> I forgot to give you a URL
>
> www.virtelweb.com
>
>
> You could download and test it for
> 5 users
>
> If you need support
> You can send me a mail wolfgang.fr...@wfs-gmbh.eu
>
>
>
> Bin unterwegs hab nur iPhone zur Verfügung.
>
> > Am 18.08.2017 um 14:08 schrieb william janulin <008d52e04f2e-dmarc-
> requ...@listserv.ua.edu>:
> >
> > There is also TUBES from Macro 4.
> >
> >
> >On Friday, August 18, 2017 7:53 AM, Wolfgang Fritz <
> 016acdc52809-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >
> > Hi
> > There is another possibility try
> > Syspertec Virtel there is a Session manager
> > Included and you could earn your 3270 emulation you work only browser
> based with a http/SNA gateway
> > RegArds
> > Wolfgang
> > --
> > 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
>

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


Re: Possible COBOL RFE to abend if any warnings occured

2017-08-18 Thread Farley, Peter x23353
I agree with Jeffrey's comment and will add one of my own:  No program should 
be installed into QA or UAT or production libraries with SSRANGE or ZONECHECK 
or any other debugging option turned on at all.  There should be lifecycle 
software rules in place to automatically prevent it from ever happening.

Debugging options are for debugging problems and for unit and regression 
testing, never for production.  You are costing yourself serious CPU usage to 
leave them turned on in production.  When a programmer is debugging or changing 
code they should already know enough to look at the message output (batch or 
CICS) when they have debugging compiler options turned on.  If they don't know 
that then they don't deserve the label "programmer".

Like the old vaudeville routine said, "Patient: Doctor!  Doctor!  It hurts when 
I do that!"  "Doctor: Well, don't do that!"

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jeffrey Holst
Sent: Friday, August 18, 2017 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Possible COBOL RFE to abend if any warnings occured

Unless you have other specific examples, both NUMCHECK and SSRANGE already 
offer the ABD sub-option. I would think the RFE would be rejected as already 
delivered.

On Fri, 18 Aug 2017 00:19:14 +, Frank Swarbrick 
 wrote:

>Not yet submitted.  Please comment.
>
>COBOL Language Environment �warning� messages (severity code 1) are written to 
>the destination supplied by the MSGFILE runtime option.  This defaults to 
>CEEMSG for batch jobs and the CESE TD queue for CICS (where CESE is generally 
>mapped to the CEEMSG DD�)
>
>There is nothing about the execution of a program currently that will give any 
>indication that any warning conditions occurred, other than the existence of 
>these messages.  So if you want to know if a particular execution of a program 
>caused any warning conditions you must look at the appropriate output.
>
>Enterprise COBOL has recently added new compile options with sub-options ABD 
>and MSG.  When ABD is specified the program will, when certain conditions 
>occur, raise a severity 2 LE condition, which in turn (if not �handled�) will 
>cause the program to abend with code U4038 (or return code 3000 when runtime 
>option ABTERMENC(RETURN) in used instead of the default ABTERMENC(ABEND).
>
>When MSG is specified then only a severity 1 LE condition is raised.  This 
>causes COBOL to simply write the message and then continue on to the next 
>COBOL statement.
>
>Unless you are specifically thinking that your program run might have warnings 
>you may not check for them.  This is especially true for a CICS transaction, 
>since there is generally no �batch output� to review.
>
>It could be useful to have a run-time condition that optionally would be 
>raised at the termination of the run-unit (via STOP RUN or a GOBACK of the 
>�initial� program) if any COBOL warning condition was raised within the 
>run-unit.  This new condition should be at least a level 2 condition so that 
>it will in turn cause the existing CEE0198S condition to be raised if it is 
>not suppressed by a condition handler or other method, which in turn would 
>cause the U4038 abend.
>
>Use case:
>COBOL program is compiled with SSRANGE(MSG) and NUMCHECK(MSG).  When a 
>condition is raised as a result of something these options check for it causes 
>an appropriate warning message to be written to the LE MSGFILE.  As part of 
>COBOL run-unit termination it should check to see if any SEV 1 conditions 
>caused warning messages to be written.  If so it should raise a new SEV 2 (or 
>above) condition.
>
>Considerations:
>-Can/should this be done such that the current unit of work is committed 
>prior to the abend occurring?
>-Use of this feature might necessitate the ability to suppress warning 
>messages that are expected.  This would probably have to be done at compile 
>time.  Perhaps a new �compiler directive� statement could be used to 
>�surround� code that causes a warning condition to occur but where you want to 
>suppress the warning.
>
>Other discussion:
>I thought that I might be able to code this myself as a condition handler 
>which I would then specify as the second parameter to the USRHDLR run-time 
>option.  I could not get this to work, because it appears that you cannot 
>�promote� the CEE0199W condition to another condition.
>
>Additionally, if you end your run-unit via a GOBACK instead of a STOP RUN it 
>does not cause any condition to occur, and thus the handler is not invoked at 
>run-unit termination.  So there would be no way to cause a new condition via 
>the handler in this case.
>Frank
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the 

Re: SMFLIMxx sample?

2017-08-18 Thread Steve

Hello,

Kees, sorry for the delay in answering:

>You say: "Note that SMFLIMxx REGIONBELOW/REGIONABOVE are *not* related 
to the IEFUSI's "region size" parameter"
>Am I correct to state that SMFLIMxx REGIONBELOW/REGIONABOVE are equal 
to IEFUSI setting a Regionsize=Regionlimit both below and above?


sbj:  As the function exists now, VSM sets the job step's limit and size 
values using a myriad of fields passed into it:

- JCL Region= or REGIONX= values
- SMFLIMxx REGIONx values (which will override the above JCL REGION 
values)

- IEFUSI RegionLimit and RegionSize values
- SMFLIMxx SYSRESVx values, which will essentially be used in place 
of the IEFUSI REGIONLIMIT value.


VSM will factor these values together and come up with a regionlimit and 
a regionsize.


Since there is no regionsize keyword, when SYSRESV is used, the 
regionsize should match the regionlimit.


If the JCL REGION or the SMFLIMxx REGIONx values are non-zero and 
lower than the determined regionlimit, that means the user (or SMFLIMxx 
coder) has a specific amount in mind and the regionsize will be set to 
that amount.  And as we know, if you request more region via JCL than is 
available, an abend will result.  IIRC, if SYSRESVx is not used and 
IEFUSI doesn't set any values, VSM will add a default value to the 
regionsize to set the regionlimit.


This is why people are simply coding REGIONBELOW(NOLIMIT) 
REGIONABOVE(NOLIMIT) to simply override whatever the user requested and 
giving them REGION=0M. I'm not sure why they aren't using SYSRESVx 
to protect private for system use, unless they still have their IEFUSI 
in place.


>IEFUSI doc explains the value of difference between regionsize and 
regionlimit with regard to VL Getmains. Is this no important anymore, 
because SMFLIMxx does not provide control of a different regionlimit 
anymore?
SBJ: I won't say it's not important, just that it was not in the 
function provided on day 1.  And that the nuance about VL Getmains is 
often missed.


>Region=0M implies Memlimit=0M. Does the SMFLIMxx Memlimit parameter 
overrule Memlimit=0M for Region=0M tasks?
sbj:  REGION=0M implies Memlimit=0M, but only when coded on the JCL. 
Using REGIONx(NOLIMIT) does not specifically alter the MEMLIMIT. The 
SMFLIMxx memlimit parameter will overrule the MEMLIMIT coded and the 
implied memlimit from region=0M.  Since IEFUSI and SMFLIMxx have the 
ability to set any MEMLIMIT, there is no reason to imply a memlimit.




>If so, a filter on REGION= would be helpful or I need IEFUSI to ignore 
SMFLIMxx for Region=0M steps.
sbj:  Please open an RFE in DeveloperWorks.  I think you'll get a lot of 
votes for the idea.



>Does NOHONORIEFUSIREGION in SCHEDxx also apply to SMFLIMxx, i.o.w. is 
SMFLIMxx also ignored like IEFUSI is? If so, will SCHEDxx docs be updated?
sbj:  NOHONORIEFUSIREGION does override SMFLIMxx. I'll make a note to 
get the doc updated.


Thanks,
Kees.

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


Re: SMFLIMxx parameter

2017-08-18 Thread Steve
Do you have the IEF043I joblog message and the SMFLIMxx rules that you 
could post?  Along with whatever messages you get for the refusal to run...


- Steve



On 8/17/2017 1:03 PM, Adams, Anne , DTI wrote:

Hello Friends,

Has anyone had any success using (or diagnosing failures) when using the 
SMFLIMxx parameter? We have a few CICS and database regions and one unrepentant 
job that refuse to run.

Anne R. Adams, CISSP
DTI, Systems Engineering
Sr. Mainframe Services Analyst
302.298.3196


--
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: Possible COBOL RFE to abend if any warnings occured

2017-08-18 Thread Jeffrey Holst
Unless you have other specific examples, both NUMCHECK and SSRANGE already 
offer the ABD sub-option. I would think the RFE would be rejected as already 
delivered.

On Fri, 18 Aug 2017 00:19:14 +, Frank Swarbrick 
 wrote:

>Not yet submitted.  Please comment.
>
>COBOL Language Environment �warning� messages (severity code 1) are written to 
>the destination supplied by the MSGFILE runtime option.  This defaults to 
>CEEMSG for batch jobs and the CESE TD queue for CICS (where CESE is generally 
>mapped to the CEEMSG DD�)
>
>There is nothing about the execution of a program currently that will give any 
>indication that any warning conditions occurred, other than the existence of 
>these messages.  So if you want to know if a particular execution of a program 
>caused any warning conditions you must look at the appropriate output.
>
>Enterprise COBOL has recently added new compile options with sub-options ABD 
>and MSG.  When ABD is specified the program will, when certain conditions 
>occur, raise a severity 2 LE condition, which in turn (if not �handled�) will 
>cause the program to abend with code U4038 (or return code 3000 when runtime 
>option ABTERMENC(RETURN) in used instead of the default ABTERMENC(ABEND).
>
>When MSG is specified then only a severity 1 LE condition is raised.  This 
>causes COBOL to simply write the message and then continue on to the next 
>COBOL statement.
>
>Unless you are specifically thinking that your program run might have warnings 
>you may not check for them.  This is especially true for a CICS transaction, 
>since there is generally no �batch output� to review.
>
>It could be useful to have a run-time condition that optionally would be 
>raised at the termination of the run-unit (via STOP RUN or a GOBACK of the 
>�initial� program) if any COBOL warning condition was raised within the 
>run-unit.  This new condition should be at least a level 2 condition so that 
>it will in turn cause the existing CEE0198S condition to be raised if it is 
>not suppressed by a condition handler or other method, which in turn would 
>cause the U4038 abend.
>
>Use case:
>COBOL program is compiled with SSRANGE(MSG) and NUMCHECK(MSG).  When a 
>condition is raised as a result of something these options check for it causes 
>an appropriate warning message to be written to the LE MSGFILE.  As part of 
>COBOL run-unit termination it should check to see if any SEV 1 conditions 
>caused warning messages to be written.  If so it should raise a new SEV 2 (or 
>above) condition.
>
>Considerations:
>-Can/should this be done such that the current unit of work is committed 
>prior to the abend occurring?
>-Use of this feature might necessitate the ability to suppress warning 
>messages that are expected.  This would probably have to be done at compile 
>time.  Perhaps a new �compiler directive� statement could be used to 
>�surround� code that causes a warning condition to occur but where you want to 
>suppress the warning.
>
>Other discussion:
>I thought that I might be able to code this myself as a condition handler 
>which I would then specify as the second parameter to the USRHDLR run-time 
>option.  I could not get this to work, because it appears that you cannot 
>�promote� the CEE0199W condition to another condition.
>
>Additionally, if you end your run-unit via a GOBACK instead of a STOP RUN it 
>does not cause any condition to occur, and thus the handler is not invoked at 
>run-unit termination.  So there would be no way to cause a new condition via 
>the handler in this case.
>Frank
>
>--
>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 Session Manager replacement

2017-08-18 Thread Wolfgang Fritz
Hi 
I forgot to give you a URL 

www.virtelweb.com


You could download and test it for
5 users 

If you need support
You can send me a mail wolfgang.fr...@wfs-gmbh.eu



Bin unterwegs hab nur iPhone zur Verfügung.

> Am 18.08.2017 um 14:08 schrieb william janulin 
> <008d52e04f2e-dmarc-requ...@listserv.ua.edu>:
> 
> There is also TUBES from Macro 4.
> 
> 
>On Friday, August 18, 2017 7:53 AM, Wolfgang Fritz 
> <016acdc52809-dmarc-requ...@listserv.ua.edu> wrote:
> 
> 
> Hi
> There is another possibility try
> Syspertec Virtel there is a Session manager
> Included and you could earn your 3270 emulation you work only browser based 
> with a http/SNA gateway
> RegArds
> Wolfgang
> --
> 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 Session Manager replacement

2017-08-18 Thread william janulin
There is also TUBES from Macro 4.
 

On Friday, August 18, 2017 7:53 AM, Wolfgang Fritz 
<016acdc52809-dmarc-requ...@listserv.ua.edu> wrote:
 

 Hi
There is another possibility try
Syspertec Virtel there is a Session manager
Included and you could earn your 3270 emulation you work only browser based 
with a http/SNA gateway
RegArds
Wolfgang
--
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 Session Manager replacement

2017-08-18 Thread Wolfgang Fritz
Hi
There is another possibility try
Syspertec Virtel there is a Session manager
Included and you could earn your 3270 emulation you work only browser based 
with a http/SNA gateway
RegArds
Wolfgang
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: IBM Session Manager replacement

2017-08-18 Thread Roger Lowe
Roberto,
 Have a read of the Announcement Letter 
(https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an=ca=gpateam=897=ENUS215-356)
 for CL/Supersession and in particular the section titled "ESW trade-up - 
Ordering information"
.
You may find that it may be a NO cost option for you to go to CL/Supersession - 
possibly worth investigating
.
Hope the above helps
.
Roger

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


Re: IBM Session Manager replacement

2017-08-18 Thread Steve Austin
Tubes from Macro 4 will be the easiest in terms of migration.


Steve Austin
Product Architect
Macro 4 Limited
d: +44 1293 872261 | t: +44 1293 872000 | www.macro4.com

      

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roberto Halais
Sent: 17 August 2017 23:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM Session Manager replacement

Hi listers:

IBM has notified that IBM Session Manager product will be phased out by the end 
of 2018.

They suggest we migrate to IBM CL/Supersession.

I would like to know of other vendor products that do a similar function.

I will be searching but thought of tapping into your experience.

Thank you all for any hints.

Roberto

--
Politics: Poli (many) - tics (blood sucking parasites)

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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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