Re: DS8K thin provisioning error

[Jake Anderson]

Hello Atilla,

I do not use IEA499E anywhere in z/OS console. From ISMF all the z/OS
storage groups and non sms volumes are sufficient.



On Tue, Jul 28, 2020 at 8:59 AM Attila Fogarasi  wrote:

> z/OS fully supports thin provisioned volumes as long as you are on the
> right software level (e.g.  for DFSSMSdss APARs OA48707 and OA50675; there
> are others).
> z./OS issues console message IEA499E at the pool capacity thresholds.  Are
> you not seeing any z/OS messages?
> You can use the IDCAMS LISTDATA command to show the ESE pools.
> You can use the DS88xx DS GUI to understand and manage your pool
> configurations for non.  Normally there is some capacity reserved to grow a
> pool which reaches a limit.  Worst case you need to delete data from the
> pool, or buy more hardware :)  Or manage space in the consuming software,
> once you identify the usage.
> As for the trim events pending, that is just normal processing (some number
> of events are kept, for example 50,000, and older events are trimmed when
> reaching this limit).  The "pool over threshold" will be a recent event in
> that 50,000 and won't be trimmed :)
>
> On Tue, Jul 28, 2020 at 2:18 PM Jake Anderson 
> wrote:
>
> > Hello,
> >
> > We are using DS8866 box for our z/OS and z/VM. Today in DS8k console we
> are
> > seeing a message as
> >
> > Trim Event Pending  - Events will be trimmed in less than a week
> > Pool Over Threshold - Pool EP_EASYTIER_CKD_2 over provisioned capacity
> over
> > threshold.
> >
> > I believe Thin provisioned volumes are not used by z/OS ? Normally what
> > actions have to be taken once we receive the above message ?
> >
> >
> > Regards,
> > Jake
> >
> > --
> > 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: DS8K thin provisioning error

[Attila Fogarasi]

z/OS fully supports thin provisioned volumes as long as you are on the
right software level (e.g.  for DFSSMSdss APARs OA48707 and OA50675; there
are others).
z./OS issues console message IEA499E at the pool capacity thresholds.  Are
you not seeing any z/OS messages?
You can use the IDCAMS LISTDATA command to show the ESE pools.
You can use the DS88xx DS GUI to understand and manage your pool
configurations for non.  Normally there is some capacity reserved to grow a
pool which reaches a limit.  Worst case you need to delete data from the
pool, or buy more hardware :)  Or manage space in the consuming software,
once you identify the usage.
As for the trim events pending, that is just normal processing (some number
of events are kept, for example 50,000, and older events are trimmed when
reaching this limit).  The "pool over threshold" will be a recent event in
that 50,000 and won't be trimmed :)

On Tue, Jul 28, 2020 at 2:18 PM Jake Anderson 
wrote:

> Hello,
>
> We are using DS8866 box for our z/OS and z/VM. Today in DS8k console we are
> seeing a message as
>
> Trim Event Pending  - Events will be trimmed in less than a week
> Pool Over Threshold - Pool EP_EASYTIER_CKD_2 over provisioned capacity over
> threshold.
>
> I believe Thin provisioned volumes are not used by z/OS ? Normally what
> actions have to be taken once we receive the above message ?
>
>
> Regards,
> Jake
>
> --
> 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

DS8K thin provisioning error

[Jake Anderson]

Hello,

We are using DS8866 box for our z/OS and z/VM. Today in DS8k console we are
seeing a message as

Trim Event Pending  - Events will be trimmed in less than a week
Pool Over Threshold - Pool EP_EASYTIER_CKD_2 over provisioned capacity over
threshold.

I believe Thin provisioned volumes are not used by z/OS ? Normally what
actions have to be taken once we receive the above message ?


Regards,
Jake

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

Re: GQSCAN vs ISGQUERY

[Ed Jaffe]

On 7/27/2020 1:59 PM, Tony Harminc wrote:

Is there any clear advantage to converting to ISGQUERY?



We have no benchmark comparing ISGQUERY and GQSCAN, but our measurements 
indicate ISGENQ/ISGDEQ are slightly slower than ENQ/DEQ.


I don't think GQSCAN will ever go away. If all you need is a tweak, I 
would not convert the code.


ISGQUERY is way, Way, WAY easier to program and supports storage use of 
above the bar. All new code we write (happily) uses it.



--
Phoenix Software International
Edward E. Jaffe
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: Keeping TSO users our of CICS

[lenru...@gmail.com]

 Long ago and far away, we had a similar problem.  The VTAM applid and the CICS 
region userid were the same.  Users would type the applid twice, end up trying 
to logon to CICS as the CICS region ID, then use their userid or password and 
revoke the region userid.  
CESN is a user replaceable program, and we replaced it with a menu system, 
users didn't use transaction id's, they picked from an ISPF like menu.  I just 
added logic to the signon program to do a vtam disconnect if a region userid 
was used, no message, no mercy, get out of my CICS region :-)  
On Monday, July 27, 2020, 06:46:29 PM CDT, Steve Beaver 
 wrote:  
 
 In the bad old days we used a bit setting in the ACF2 FDR to control access to 
a CICS but I have no idea how to do that in RACF using an exit

Sent from my iPhone

I promise you I can’t type or
Spell on any smartphone 

> On Jul 27, 2020, at 17:47, Jesse 1 Robinson  wrote:
> 
> It was a long time ago, but yes, TCAS or some inbred cousin issued the WTOR 
> and whole thing waited. Much more recently TPX would do the same thing. 
> Improper coding is not the purview of user software. 
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Seymour J Metz
> Sent: Monday, July 27, 2020 3:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Keeping TSO users our of CICS
> 
> CAUTION EXTERNAL EMAIL
> 
> Do you mean that TCAS issued a WTOR? Because that's the only way I can 
> imagine TSO having had such a problem.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Jesse 1 Robinson [jesse1.robin...@sce.com]
> Sent: Monday, July 27, 2020 6:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Keeping TSO users our of CICS
> 
> This is not a 'RACF problem'. The problem lies with product that manages 
> logins using RACF. Whipper snappers believe it or not, once upon a time TSO 
> itself had this problem. The task gets a wait from RACF, but that task is 
> running in the mainline of the top guy. The proper way to handle this is to 
> put logon in a subtask, which can wait forever allowing TSO or CICS or TPX or 
> whatever to keep business running in the meantime. I'm not a CICS guy, but it 
> shocks me that such a mature product would behave this way.
> 
> Short of a CICS fix, the shop needs to change its practices. The idea of 
> assigning SPECIAL to a help desk jockey is pretty outré.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Tony Harminc
> Sent: Monday, July 27, 2020 3:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Keeping TSO users our of CICS
> 
> CAUTION EXTERNAL EMAIL
> 
> On Mon, 27 Jul 2020 at 18:03, ITschak Mugzac

--
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: OMVS CP command anomaly

[Andrew Rowley]

On 28/07/2020 4:48 am, Lionel B Dyck wrote:

Created several ISPF panels from DTL.  The result is an ISPF panel with
attribute characters that are binary (hex) with examples being x'01' ,
x'02', x'05, x'0D', and more.
  
Copying these PDS members to an OMVS filesystem using cp works fine.  The

data is NOT being copied as binary.

The problem/anomaly is copying the files from OMVS into z/OS dataset members
results in these members being corrupted with the single record  being
broken into one, or more, records.
The most likely problem is that when you copy from dataset to file, line 
end characters are being inserted at the end of every record. When you 
copy back, line end characters are used to break the data back into 
records, but the same character(s) exist in your panel definitions. Cp 
cannot tell whether it is an inserted line end character or part of your 
data.


Copying binary data as text is not guaranteed to give the correct result 
after a round-trip. Depending on the data it can be almost correct or 
even usually correct, but there is always a risk unless you can 
guarantee that the line end characters do not exist in your data.


Options:
- Maybe cp has an option where it doesn't insert/remove line endings 
e.g. like IND$FILE file transfer has separate options for binary and 
CRLF. The data would look like one long record, apart form the 
incidental line end characters in your data. This is likely to cause 
problems for git in displaying data, merging etc. (assuming this is for 
Zigi).
- Copy as binary. The best-simplest option, however it would also cause 
merge etc. problems
- Use an escape character scheme for binary characters e.g. quoted 
printable. This adds a processing step - you can't use regular cp 
command - but it gives you data in git that is mergable and mostly 
readable as text.


--
Andrew Rowley
Black Hill Software

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

Re: Keeping TSO users our of CICS

[Steve Beaver]

In the bad old days we used a bit setting in the ACF2 FDR to control access to 
a CICS but I have no idea how to do that in RACF using an exit

Sent from my iPhone

I promise you I can’t type or
Spell on any smartphone 

> On Jul 27, 2020, at 17:47, Jesse 1 Robinson  wrote:
> 
> It was a long time ago, but yes, TCAS or some inbred cousin issued the WTOR 
> and whole thing waited. Much more recently TPX would do the same thing. 
> Improper coding is not the purview of user software. 
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Seymour J Metz
> Sent: Monday, July 27, 2020 3:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Keeping TSO users our of CICS
> 
> CAUTION EXTERNAL EMAIL
> 
> Do you mean that TCAS issued a WTOR? Because that's the only way I can 
> imagine TSO having had such a problem.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Jesse 1 Robinson [jesse1.robin...@sce.com]
> Sent: Monday, July 27, 2020 6:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Keeping TSO users our of CICS
> 
> This is not a 'RACF problem'. The problem lies with product that manages 
> logins using RACF. Whipper snappers believe it or not, once upon a time TSO 
> itself had this problem. The task gets a wait from RACF, but that task is 
> running in the mainline of the top guy. The proper way to handle this is to 
> put logon in a subtask, which can wait forever allowing TSO or CICS or TPX or 
> whatever to keep business running in the meantime. I'm not a CICS guy, but it 
> shocks me that such a mature product would behave this way.
> 
> Short of a CICS fix, the shop needs to change its practices. The idea of 
> assigning SPECIAL to a help desk jockey is pretty outré.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Tony Harminc
> Sent: Monday, July 27, 2020 3:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Keeping TSO users our of CICS
> 
> CAUTION EXTERNAL EMAIL
> 
> On Mon, 27 Jul 2020 at 18:03, ITschak Mugzac

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

Re: SHAREOPTIONS from a program?

[Seymour J Metz]

CSI


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Monday, July 27, 2020 7:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SHAREOPTIONS from a program?

Simple question - I think I should know the answer, but I don't.

How can an application program using a VSAM dataset discover the
SHAREOPTIONS that were specified when the cluster was DEFINEd/ALTERed?

Can this be done easily before OPEN? After OPEN?

There are two flag bits in ACBINFL2, but that would seem not enough to
cover all the possibilities.

Thanks.

Tony H.

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

SHAREOPTIONS from a program?

[Tony Harminc]

Simple question - I think I should know the answer, but I don't.

How can an application program using a VSAM dataset discover the
SHAREOPTIONS that were specified when the cluster was DEFINEd/ALTERed?

Can this be done easily before OPEN? After OPEN?

There are two flag bits in ACBINFL2, but that would seem not enough to
cover all the possibilities.

Thanks.

Tony H.

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

Re: Started task stopping immediately. No error messages.

[Charles Mills]

Perhaps the user exit has a hard-coded exception for 'FTPD' and not for 'FTPDS'?

Well, what I say about user-hostile still stands. If it's not the FTP daemon 
that was written this way, then it is some user exit. Whatever software was 
written this way, it is inexcusable.

I don't know if the particular exit point has WTO available -- some do not -- 
but I think a documented ABEND should be an option.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe Monk
Sent: Monday, July 27, 2020 2:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Started task stopping immediately. No error messages.

IMHO, the clue to this is in his printout.

PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'

IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002

So, it looks some exit is killing the task because he has REGION=0M.

The SMFLIMxx policy is killing the task (ONOUDONT).

Joe


On Mon, Jul 27, 2020 at 4:42 PM Charles Mills  wrote:

> Oh man! Talk about user-hostile programming. How could anyone ship a
> customer-facing program that detects an error and then just quits with (a.)
> RC=0 and (b.) no message whatsoever. No "Hello World I am FTPD V2R3" and no
> error message. Even if you can't open your usual log or listing file you
> can
> WTO 'Unable to open SYSPRINT' (or whatever) or issue a documented ABEND.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Monday, July 27, 2020 8:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Started task stopping immediately. No error messages.
>
> It looks like you're using JES3. I thought thad SDSF didn't support it.
>
> CC 0 would have been a useful datum in the original question. It looks like
> the FTP server doesn't issue an informational message when a copy is
> already
> running. RFE?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of
> Skippy the Ancient [kkin...@email.com]
> Sent: Monday, July 27, 2020 8:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Started task stopping immediately. No error messages.
>
> Responding to all posters, not just Mr Metz.
>
> 1. I already tried calling the proc from JCL.  It ran, stopped immediately
> and returned no error messages.
> 2. I started the proc with the MSGCLASS and did receive output.  It was
> identical to the JCL call; immediate stop and no error messages.  I will
> post this below.
> 3. The started task is a second FTP server supporting FTPS. To simplify, I
> copied the FTPD proc and renamed it FTPSD.  In theory, it is running
> exactly
> as the original FTPD task with a different port. (990)
> 4. The PROFILE update reads like this -
> AUTOLOG
>FTPSD JOBNAME FTPSD  ; FTPS SERVER
> ENDAUTOLOG
> PORT
>989 TCP OMVS; FTPS SERVER
>990 TCP FTPSD NOAUTOLOG ; FTPS SERVER
>
> Here is the output of running the started task - (system specifics changed
> for security reasons)
>  08:26:31  IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB
> DSN=SYSX.TCPIP.SEZATCP
>  08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB
> DSN=SYSX.TCPIP.XXLOAD
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSFTPD
> DSN=SYSX.TCPIP.PARMLIB
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSTCPD
> DSN=SYSX.TCPIP.PARMLIB
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31  IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER
> FTPSD   , GROUP 
>  08:26:31  ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD
>  08:26:31  IEF403I FTPSD - STARTED - TIME=08.26.31
>  08:26:31  IEF404I FTPSD - ENDED - TIME=08.26.31
> //FTPSDJOB MSGCLASS=T, *
> // MSGLEVEL=1
> //STARTING EXEC FTPSD
> 1 //FTPSDJOB MSGCLASS=T,
> *
>   // MSGLEVEL=1
> 2 //STARTING EXEC FTPSD
> 3 XXFTPSD  PROC MODULE='FTPD',PARMS='TRACE PORT 990'
> 4 XXFTPD   EXEC PGM=&MODULE,REGION=0M,TIME=NOLIMIT,
>   XX  PARM='POSIX(ON) ALL31(ON)/&PARMS'
>   IEFC653I SUBSTITUTION JCL -
> PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'
> 5 XXSTEPLIB  DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR
> 6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR
> 7 XXCEEDUMP  DD SYSOUT=*
> 8 XXSYSOUT   DD SYSOUT=*
> 9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL)
>10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA)
>  STMT NO. MESSAGE
> 2 IEFC

Re: Keeping TSO users our of CICS

[Seymour J Metz]

Indeed. Take the Transient Queue Manager - Please!


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jesse 1 Robinson [jesse1.robin...@sce.com]
Sent: Monday, July 27, 2020 6:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Keeping TSO users our of CICS

It was a long time ago, but yes, TCAS or some inbred cousin issued the WTOR and 
whole thing waited. Much more recently TPX would do the same thing. Improper 
coding is not the purview of user software.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Monday, July 27, 2020 3:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping TSO users our of CICS

CAUTION EXTERNAL EMAIL

Do you mean that TCAS issued a WTOR? Because that's the only way I can imagine 
TSO having had such a problem.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jesse 1 Robinson [jesse1.robin...@sce.com]
Sent: Monday, July 27, 2020 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Keeping TSO users our of CICS

This is not a 'RACF problem'. The problem lies with product that manages logins 
using RACF. Whipper snappers believe it or not, once upon a time TSO itself had 
this problem. The task gets a wait from RACF, but that task is running in the 
mainline of the top guy. The proper way to handle this is to put logon in a 
subtask, which can wait forever allowing TSO or CICS or TPX or whatever to keep 
business running in the meantime. I'm not a CICS guy, but it shocks me that 
such a mature product would behave this way.

Short of a CICS fix, the shop needs to change its practices. The idea of 
assigning SPECIAL to a help desk jockey is pretty outré.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Monday, July 27, 2020 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping TSO users our of CICS

CAUTION EXTERNAL EMAIL

On Mon, 27 Jul 2020 at 18:03, ITschak Mugzach  wrote:

> It happens because racf is a single task. This is why other users
> can't login until the wtor is replied.
>

I very much doubt this. It may be that this part of *CICS* is a single task for 
all its users, but RACF itself pretty much runs as a subroutine of the caller 
of RACROUTE. So it is up to CICS to not get caught up in this wait.

Tony H.


--
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: Keeping TSO users our of CICS

[Jesse 1 Robinson]

It was a long time ago, but yes, TCAS or some inbred cousin issued the WTOR and 
whole thing waited. Much more recently TPX would do the same thing. Improper 
coding is not the purview of user software. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Monday, July 27, 2020 3:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping TSO users our of CICS

CAUTION EXTERNAL EMAIL

Do you mean that TCAS issued a WTOR? Because that's the only way I can imagine 
TSO having had such a problem.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jesse 1 Robinson [jesse1.robin...@sce.com]
Sent: Monday, July 27, 2020 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Keeping TSO users our of CICS

This is not a 'RACF problem'. The problem lies with product that manages logins 
using RACF. Whipper snappers believe it or not, once upon a time TSO itself had 
this problem. The task gets a wait from RACF, but that task is running in the 
mainline of the top guy. The proper way to handle this is to put logon in a 
subtask, which can wait forever allowing TSO or CICS or TPX or whatever to keep 
business running in the meantime. I'm not a CICS guy, but it shocks me that 
such a mature product would behave this way.

Short of a CICS fix, the shop needs to change its practices. The idea of 
assigning SPECIAL to a help desk jockey is pretty outré.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Monday, July 27, 2020 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping TSO users our of CICS

CAUTION EXTERNAL EMAIL

On Mon, 27 Jul 2020 at 18:03, ITschak Mugzach  wrote:

> It happens because racf is a single task. This is why other users 
> can't login until the wtor is replied.
>

I very much doubt this. It may be that this part of *CICS* is a single task for 
all its users, but RACF itself pretty much runs as a subroutine of the caller 
of RACROUTE. So it is up to CICS to not get caught up in this wait.

Tony H.


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

Re: Keeping TSO users our of CICS

[Seymour J Metz]

Do you mean that TCAS issued a WTOR? Because that's the only way I can imagine 
TSO having had such a problem.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jesse 1 Robinson [jesse1.robin...@sce.com]
Sent: Monday, July 27, 2020 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Keeping TSO users our of CICS

This is not a 'RACF problem'. The problem lies with product that manages logins 
using RACF. Whipper snappers believe it or not, once upon a time TSO itself had 
this problem. The task gets a wait from RACF, but that task is running in the 
mainline of the top guy. The proper way to handle this is to put logon in a 
subtask, which can wait forever allowing TSO or CICS or TPX or whatever to keep 
business running in the meantime. I'm not a CICS guy, but it shocks me that 
such a mature product would behave this way.

Short of a CICS fix, the shop needs to change its practices. The idea of 
assigning SPECIAL to a help desk jockey is pretty outré.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Monday, July 27, 2020 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping TSO users our of CICS

CAUTION EXTERNAL EMAIL

On Mon, 27 Jul 2020 at 18:03, ITschak Mugzach  wrote:

> It happens because racf is a single task. This is why other users
> can't login until the wtor is replied.
>

I very much doubt this. It may be that this part of *CICS* is a single task for 
all its users, but RACF itself pretty much runs as a subroutine of the caller 
of RACROUTE. So it is up to CICS to not get caught up in this wait.

Tony H.

--
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: Keeping TSO users our of CICS

[Jesse 1 Robinson]

This is not a 'RACF problem'. The problem lies with product that manages logins 
using RACF. Whipper snappers believe it or not, once upon a time TSO itself had 
this problem. The task gets a wait from RACF, but that task is running in the 
mainline of the top guy. The proper way to handle this is to put logon in a 
subtask, which can wait forever allowing TSO or CICS or TPX or whatever to keep 
business running in the meantime. I'm not a CICS guy, but it shocks me that 
such a mature product would behave this way.

Short of a CICS fix, the shop needs to change its practices. The idea of 
assigning SPECIAL to a help desk jockey is pretty outré. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Monday, July 27, 2020 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping TSO users our of CICS

CAUTION EXTERNAL EMAIL

On Mon, 27 Jul 2020 at 18:03, ITschak Mugzach  wrote:

> It happens because racf is a single task. This is why other users 
> can't login until the wtor is replied.
>

I very much doubt this. It may be that this part of *CICS* is a single task for 
all its users, but RACF itself pretty much runs as a subroutine of the caller 
of RACROUTE. So it is up to CICS to not get caught up in this wait.

Tony H.

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

Re: [External] Re: Started task stopping immediately. No error messages.

[Pommier, Rex]

Nice catch, Joe.

Charles,

I would agree about a customer-facing process not generating messages upon 
termination.  However, the FTP daemon isn't "quite" that bad.  Just for 
curiosity, I tried to start a second FTPD on my sandbox.  It did what it was 
supposed to do, started the FTPD1 daemon and shut itself down.  The new daemon 
shut down immediately too.  It didn't say why, but it at least did say it was 
shutting down.  

S FTPD < me starting it
$HASP100 FTPD ON STCINRDR  
IEF695I START FTPD WITH JOBNAME FTPD IS ASSIGNED TO USER FTPD  
 , GROUP SPTDFGRP  
$HASP373 FTPD STARTED  
IEF403I FTPD - STARTED - TIME=16.56.41 
IRR812I PROFILE BPXAS*.* (G) IN THE STARTED CLASS WAS USED 722 
TO START BPXAS WITH JOBNAME BPXAS. 
$HASP100 BPXASON STCINRDR  
$HASP373 BPXASSTARTED  
IEF403I BPXAS - STARTED - TIME=16.56.41
BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB FTPD RUNNING IN ASID 
007D   
IEF404I FTPD - ENDED - TIME=16.56.41   
$HASP395 FTPD ENDED - RC=  
IEA989I SLIP TRAP ID=X33E MATCHED.  JOBNAME=*UNAVAIL, ASID=007D.   
EZY2714I FTP server shutdown in progress   
EZYFT59I FTP shutdown complete.


Just for giggles, I meandered over into the Unix services syslog.log and found 
this (granted I didn't use a different port for the second daemon):

(snipped for brevity)
ftpdÝ1907¨: EZY2700I Using port FTP control (21)

ftpdÝ1907¨: EZY2701I Inactivity time is 300 

ftpdÝ1907¨: EZYFT13E bind error : EDC8115I Address already in use. 
(errno2=0x744C7247)  
ftpdÝ1907¨: EZY2714I FTP server shutdown in progress

ftpdÝ1907¨: EZYFT59I FTP shutdown complete. 


So FTPD does indicate what the problem is when it doesn't start up properly.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Monday, July 27, 2020 4:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Started task stopping immediately. No error messages.

IMHO, the clue to this is in his printout.

PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'

IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002

So, it looks some exit is killing the task because he has REGION=0M.

The SMFLIMxx policy is killing the task (ONOUDONT).

Joe


On Mon, Jul 27, 2020 at 4:42 PM Charles Mills  wrote:

> Oh man! Talk about user-hostile programming. How could anyone ship a 
> customer-facing program that detects an error and then just quits with 
> (a.)
> RC=0 and (b.) no message whatsoever. No "Hello World I am FTPD V2R3" 
> and no error message. Even if you can't open your usual log or listing 
> file you can WTO 'Unable to open SYSPRINT' (or whatever) or issue a 
> documented ABEND.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Seymour J Metz
> Sent: Monday, July 27, 2020 8:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Started task stopping immediately. No error messages.
>
> It looks like you're using JES3. I thought thad SDSF didn't support it.
>
> CC 0 would have been a useful datum in the original question. It looks 
> like the FTP server doesn't issue an informational message when a copy 
> is already running. RFE?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Skippy the Ancient [kkin...@email.com]
> Sent: Monday, July 27, 2020 8:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Started task stopping immediately. No error messages.
>
> Responding to all posters, not just Mr Metz.
>
> 1. I already tried calling the proc from JCL.  It ran, stopped 
> immediately and returned no error messages.
> 2. I started the proc with the MSGCLASS and did receive output.  It 
> was identical to the JCL call; immediate stop and no error messages.  
> I will post this below.
> 3. The started task is a second FTP server supporting FTPS. To 
> simplify, I copied the FTPD proc and renamed it FTPSD.  In theory, it 
> is running exactly as the original FTPD task with a different port. 
> (990) 4. The PROFILE update reads like this - AUTOLOG
>FTPSD JOBNAME F

Re: Keeping TSO users our of CICS

[Tony Harminc]

On Mon, 27 Jul 2020 at 18:03, ITschak Mugzach  wrote:

> It happens because racf is a single task. This is why other users can't
> login until the wtor is replied.
>

I very much doubt this. It may be that this part of *CICS* is a single task
for all its users, but RACF itself pretty much runs as a subroutine of the
caller of RACROUTE. So it is up to CICS to not get caught up in this wait.

Tony H.

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

Re: Keeping TSO users our of CICS

[ITschak Mugzach]

It happens because racf is a single task. This is why other users can't
login until the wtor is replied.



ITschak

בתאריך יום ג׳, 28 ביולי 2020, 0:13, מאת Jesse 1 Robinson ‏<
jesse1.robin...@sce.com>:

> I think we're asking the wrong question. These folk just make an ordinary
> fat fingered typo now and then. If that happens on TSO, the user is hung up
> but the system runs along fine. Apparently in CICS, the whole shebang goes
> into a wait. I've seen this for other non-CICS products.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Itschak Mugzach
> Sent: Monday, July 27, 2020 2:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Keeping TSO users our of CICS
>
> CAUTION EXTERNAL EMAIL
>
> CICS does not require a CICS segment, so if you do not block the user at
> the APPL, the default user CICS segment inherented to the user. Still don't
> understand why the helpdesk users password authentication fails if it works
> under TSO.
>
> ITschak
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
> and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*
>
>
>
>
>
> On Mon, Jul 27, 2020 at 11:57 PM Clark Morris 
> wrote:
>
> > [Default] On 27 Jul 2020 13:40:48 -0700, in bit.listserv.ibm-main
> > stars...@mindspring.com (Lizette Koehler) wrote:
> >
> > >First if you have not done so, you might want to join the CICS or
> > >RACF Lists.
> >
> > While I am at least 20 years out of date, it used to be that someone
> > had to be set up in each CICS region they were allowed to access.  So
> > far as I know access to TSO does not automatically get you access to
> > CICS and having access to CICS test does not mean access to CICS
> > production or even CICS test for a different region.
> >
> > Clark Morris
> > >
> > >I think the IRR profiles can avoid the use of SPECIAL and OPERATIONS,
> > >but you would need to research that
> > >
> > >
> > >I think the RACF List may be more helpful
> > >
> > >CICS   http://www.listserv.uga.edu/archives/cics-l.html
> > >RACF   http://www.listserv.uga.edu/archives/racf-l.html
> > >
> > >
> > >Next I think here are IRR profiles that can be used to reset
> > >passwords.  I am not very familiar with it, I think this
> > >
> > >
> > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo
> > s.v2r1
> >
> > >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_password
> > >s_by_gr
> > >oup_tree.htm
> > >
> > >
> > >Steps for delegating the authority to reset passwords by group tree
> > >
> > >Before you begin:
> > >
> > >Make sure the ALTUSER command issuer does not have similar access
> > > to
> > the
> > >IRR.PASSWORD.RESET resource in the FACILITY class.
> > >Ensure that list-of-groups-checking (SETROPTS GRPLIST) is enabled.
> > >
> > >Perform the following steps to limit the authority of a general user
> > >or group to resume user IDs and reset passwords and password phrases
> > >based on the scope of a group tree.
> > >
> > >Define the following generic profiles in the FACILITY class, if
> > >not already defined. Doing so ensures that an existing generic
> > >profile does
> > not
> > >inadvertently prevent you from successfully limiting this authority.
> > >Example:
> > >
> > >RDEFINE FACILITY IRR.PASSWORD.RESET.**  UACC(NONE)
> > >RDEFINE FACILITY IRR.PWRESET.** UACC(NONE)
> > >RDEFINE FACILITY IRR.PWRESET.EXCLUDE.** UACC(READ)
> > >
> > >If you use UPDATE or CONTROL access for any IRR.PWRESET profile,
> > >as described in Table 1, specify the higher level (UPDATE or CONTROL)
> > >with
> > the
> > >UACC operand for the IRR.PWRESET.EXCLUDE.** profile instead of the
> > >UACC(READ) option shown in this example.
> > >Define a profile to protect the IRR.PWRESET.TREE.owner resource
> > >in the FACILITY class, where owner is the group that is at the top of
> > >a group
> > tree.
> > >Example:
> > >
> > >RDEFINE FACILITY IRR.PWRESET.TREE.GROUP1 UACC(NONE)
> > >   AUDIT(FAILURES(NONE) SUCCESSES(READ))
> > >
> > >
> > >
> > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo
> > s.v2r1
> >
> > >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_the_pass
> > >word_fo
> > >r_any_user.htm
> > >
> > >Steps for delegating the authority to reset the password for any user
> > >Perform the following steps to authorize a general user or group to
> > >use
> > the
> > >ALTUSER command to resume a revoked user or reset a user's password
> > >or password phrase.
> > >
> > >Define a profile to protect the IRR.PASSWORD.RESET resource in
> > >the FACI

Re: Started task stopping immediately. No error messages.

[Joe Monk]

IMHO, the clue to this is in his printout.

PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'

IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002

So, it looks some exit is killing the task because he has REGION=0M.

The SMFLIMxx policy is killing the task (ONOUDONT).

Joe


On Mon, Jul 27, 2020 at 4:42 PM Charles Mills  wrote:

> Oh man! Talk about user-hostile programming. How could anyone ship a
> customer-facing program that detects an error and then just quits with (a.)
> RC=0 and (b.) no message whatsoever. No "Hello World I am FTPD V2R3" and no
> error message. Even if you can't open your usual log or listing file you
> can
> WTO 'Unable to open SYSPRINT' (or whatever) or issue a documented ABEND.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Monday, July 27, 2020 8:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Started task stopping immediately. No error messages.
>
> It looks like you're using JES3. I thought thad SDSF didn't support it.
>
> CC 0 would have been a useful datum in the original question. It looks like
> the FTP server doesn't issue an informational message when a copy is
> already
> running. RFE?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of
> Skippy the Ancient [kkin...@email.com]
> Sent: Monday, July 27, 2020 8:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Started task stopping immediately. No error messages.
>
> Responding to all posters, not just Mr Metz.
>
> 1. I already tried calling the proc from JCL.  It ran, stopped immediately
> and returned no error messages.
> 2. I started the proc with the MSGCLASS and did receive output.  It was
> identical to the JCL call; immediate stop and no error messages.  I will
> post this below.
> 3. The started task is a second FTP server supporting FTPS. To simplify, I
> copied the FTPD proc and renamed it FTPSD.  In theory, it is running
> exactly
> as the original FTPD task with a different port. (990)
> 4. The PROFILE update reads like this -
> AUTOLOG
>FTPSD JOBNAME FTPSD  ; FTPS SERVER
> ENDAUTOLOG
> PORT
>989 TCP OMVS; FTPS SERVER
>990 TCP FTPSD NOAUTOLOG ; FTPS SERVER
>
> Here is the output of running the started task - (system specifics changed
> for security reasons)
>  08:26:31  IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB
> DSN=SYSX.TCPIP.SEZATCP
>  08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB
> DSN=SYSX.TCPIP.XXLOAD
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSFTPD
> DSN=SYSX.TCPIP.PARMLIB
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSTCPD
> DSN=SYSX.TCPIP.PARMLIB
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31  IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER
> FTPSD   , GROUP 
>  08:26:31  ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD
>  08:26:31  IEF403I FTPSD - STARTED - TIME=08.26.31
>  08:26:31  IEF404I FTPSD - ENDED - TIME=08.26.31
> //FTPSDJOB MSGCLASS=T, *
> // MSGLEVEL=1
> //STARTING EXEC FTPSD
> 1 //FTPSDJOB MSGCLASS=T,
> *
>   // MSGLEVEL=1
> 2 //STARTING EXEC FTPSD
> 3 XXFTPSD  PROC MODULE='FTPD',PARMS='TRACE PORT 990'
> 4 XXFTPD   EXEC PGM=&MODULE,REGION=0M,TIME=NOLIMIT,
>   XX  PARM='POSIX(ON) ALL31(ON)/&PARMS'
>   IEFC653I SUBSTITUTION JCL -
> PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'
> 5 XXSTEPLIB  DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR
> 6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR
> 7 XXCEEDUMP  DD SYSOUT=*
> 8 XXSYSOUT   DD SYSOUT=*
> 9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL)
>10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA)
>  STMT NO. MESSAGE
> 2 IEFC001I PROCEDURE FTPSD WAS EXPANDED USING SYSTEM LIBRARY
> SYSX.PROCLIB
> IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD   ,
> GROUP USSGRPX
> IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
> Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002
> IEF142I FTPSD FTPSD - STEP WAS EXECUTED - COND CODE 
> IEF373I STEP/FTPD/START 2020209.0826
> IEF032I STEP/FTPD/STOP  2020209.0826
> CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00
> SEC
> VIRT:80K  SYS:   216K  EXT: 2220K  SYS: 9108K
> ATB- REAL:12K  SLOTS: 0K
>  

Re: OMVS CP command anomaly

[Paul Gilmartin]

On Mon, 27 Jul 2020 15:49:52 -0500, Lionel B Dyck wrote:

>Example of the issue:
>
>ISPF Panel code:
>
>)ATTR
>  0D TYPE(PS)
>  05 TYPE(PS)
>. . .
>)BODY
>
>Ideally would like a workstation IDE user to be able to view the data and 
>perhaps update it and at some point return to z/OS for use.
>
This depends on the workstation users' having editors that
can deal with nondisplayable characters.

Aggravated by ASCII<=>EBCDIC.

I suppose that since ISPF supports hex editing, it was a natural
design choice to rely on nondisplayable characters in ISPF panel
definitions.

Using an ISPF look-alike on the workstation hardly solves the problem.

-- gil

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

Re: Keeping TSO users our of CICS

[Joe Monk]

You can get around the problem with an MPF exit to automatically REVOKE.
Look at CBT 708.

Joe

On Mon, Jul 27, 2020 at 3:32 PM McCabe, Ron 
wrote:

> Hello IBM Listers,
>
> Got an interesting problem that I would like to know how we can avoid.
> Our Help Desk users TSO accounts have the SPECIAL ATTRIBUTE so they can
> reset passwords and define new users.  These TSO accounts are not defined
> to CICS but every once in awhile one of them will try to login to CICS
> using their TSO account and after messing up their password 3 times the
> system puts out an ICH302D message asking if we want to REVOKE them or let
> them try again (we REVOKE), this message waits for a reply and while it is
> waiting CICS hangs until a reply is given.  We thought about defining their
> TSO accounts to CICS but that does not help if they actually do mess up
> their password.  We thought we could do it with RACF but RACF doesn't check
> any authorization until "after" the user successfully signs on so we would
> still get the ICH302D message.
>
> Does anyone else run into this problem?  Is there a way we can get around
> this problem?  We thought about having MSGTABLE do an automated response
> but there could be times when we don't want to have the user REVOKED.
>
> Thanks,
> Ron McCabe
> Manager of Mainframe/Midrange Systems
> Mutual of Enumclaw
>
>
> Confidentiality Notice: This e- mail and all attachments may contain
> CONFIDENTIAL information and are meant solely for the intended recipient.
> It may contain controlled, privileged, or proprietary information that is
> protected under applicable law and shall not be disclosed to any
> unauthorized third party. If you are not the intended recipient, you are
> hereby notified that any unauthorized review, action, disclosure,
> distribution, or reproduction of any information contained in this e- mail
> and any attachments is strictly PROHIBITED. If you received this e- mail in
> error, please reply to the sender immediately stating that this
> transmission was misdirected, and delete or destroy all electronic and
> paper copies of this e-mail and attachments without disclosing the
> contents. This e- mail does not grant or assign rights of ownership in the
> proprietary subject matter herein, nor shall it be construed as a joint
> venture, partnership, teaming agreement, or any other formal business
> relationship.
>
> --
> 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: Started task stopping immediately. No error messages.

[Charles Mills]

Oh man! Talk about user-hostile programming. How could anyone ship a
customer-facing program that detects an error and then just quits with (a.)
RC=0 and (b.) no message whatsoever. No "Hello World I am FTPD V2R3" and no
error message. Even if you can't open your usual log or listing file you can
WTO 'Unable to open SYSPRINT' (or whatever) or issue a documented ABEND.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, July 27, 2020 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Started task stopping immediately. No error messages.

It looks like you're using JES3. I thought thad SDSF didn't support it.

CC 0 would have been a useful datum in the original question. It looks like
the FTP server doesn't issue an informational message when a copy is already
running. RFE?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Skippy the Ancient [kkin...@email.com]
Sent: Monday, July 27, 2020 8:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Started task stopping immediately. No error messages.

Responding to all posters, not just Mr Metz.

1. I already tried calling the proc from JCL.  It ran, stopped immediately
and returned no error messages.
2. I started the proc with the MSGCLASS and did receive output.  It was
identical to the JCL call; immediate stop and no error messages.  I will
post this below.
3. The started task is a second FTP server supporting FTPS. To simplify, I
copied the FTPD proc and renamed it FTPSD.  In theory, it is running exactly
as the original FTPD task with a different port. (990)
4. The PROFILE update reads like this -
AUTOLOG
   FTPSD JOBNAME FTPSD  ; FTPS SERVER
ENDAUTOLOG
PORT
   989 TCP OMVS; FTPS SERVER
   990 TCP FTPSD NOAUTOLOG ; FTPS SERVER

Here is the output of running the started task - (system specifics changed
for security reasons)
 08:26:31  IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB
DSN=SYSX.TCPIP.SEZATCP
 08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB
DSN=SYSX.TCPIP.XXLOAD
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSFTPD
DSN=SYSX.TCPIP.PARMLIB
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSTCPD
DSN=SYSX.TCPIP.PARMLIB
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31  IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER
FTPSD   , GROUP 
 08:26:31  ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD
 08:26:31  IEF403I FTPSD - STARTED - TIME=08.26.31
 08:26:31  IEF404I FTPSD - ENDED - TIME=08.26.31
//FTPSDJOB MSGCLASS=T, *
// MSGLEVEL=1
//STARTING EXEC FTPSD
1 //FTPSDJOB MSGCLASS=T,
*
  // MSGLEVEL=1
2 //STARTING EXEC FTPSD
3 XXFTPSD  PROC MODULE='FTPD',PARMS='TRACE PORT 990'
4 XXFTPD   EXEC PGM=&MODULE,REGION=0M,TIME=NOLIMIT,
  XX  PARM='POSIX(ON) ALL31(ON)/&PARMS'
  IEFC653I SUBSTITUTION JCL -
PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'
5 XXSTEPLIB  DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR
6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR
7 XXCEEDUMP  DD SYSOUT=*
8 XXSYSOUT   DD SYSOUT=*
9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL)
   10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA)
 STMT NO. MESSAGE
2 IEFC001I PROCEDURE FTPSD WAS EXPANDED USING SYSTEM LIBRARY
SYSX.PROCLIB
IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD   ,
GROUP USSGRPX
IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002
IEF142I FTPSD FTPSD - STEP WAS EXECUTED - COND CODE 
IEF373I STEP/FTPD/START 2020209.0826
IEF032I STEP/FTPD/STOP  2020209.0826
CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC
VIRT:80K  SYS:   216K  EXT: 2220K  SYS: 9108K
ATB- REAL:12K  SLOTS: 0K
 VIRT- ALLOC:   7M SHRD:   0M
IEF375I  JOB/FTPSD   /START 2020209.0826
IEF033I  JOB/FTPSD   /STOP  2020209.0826
CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC

--
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: Keeping TSO users our of CICS

[Jesse 1 Robinson]

I think we're asking the wrong question. These folk just make an ordinary fat 
fingered typo now and then. If that happens on TSO, the user is hung up but the 
system runs along fine. Apparently in CICS, the whole shebang goes into a wait. 
I've seen this for other non-CICS products.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Itschak Mugzach
Sent: Monday, July 27, 2020 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Keeping TSO users our of CICS

CAUTION EXTERNAL EMAIL

CICS does not require a CICS segment, so if you do not block the user at the 
APPL, the default user CICS segment inherented to the user. Still don't 
understand why the helpdesk users password authentication fails if it works 
under TSO.

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and 
IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Mon, Jul 27, 2020 at 11:57 PM Clark Morris  wrote:

> [Default] On 27 Jul 2020 13:40:48 -0700, in bit.listserv.ibm-main 
> stars...@mindspring.com (Lizette Koehler) wrote:
>
> >First if you have not done so, you might want to join the CICS or 
> >RACF Lists.
>
> While I am at least 20 years out of date, it used to be that someone 
> had to be set up in each CICS region they were allowed to access.  So 
> far as I know access to TSO does not automatically get you access to 
> CICS and having access to CICS test does not mean access to CICS 
> production or even CICS test for a different region.
>
> Clark Morris
> >
> >I think the IRR profiles can avoid the use of SPECIAL and OPERATIONS, 
> >but you would need to research that
> >
> >
> >I think the RACF List may be more helpful
> >
> >CICS   http://www.listserv.uga.edu/archives/cics-l.html
> >RACF   http://www.listserv.uga.edu/archives/racf-l.html
> >
> >
> >Next I think here are IRR profiles that can be used to reset 
> >passwords.  I am not very familiar with it, I think this
> >
> >
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo
> s.v2r1
>
> >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_password
> >s_by_gr
> >oup_tree.htm
> >
> >
> >Steps for delegating the authority to reset passwords by group tree
> >
> >Before you begin:
> >
> >Make sure the ALTUSER command issuer does not have similar access 
> > to
> the
> >IRR.PASSWORD.RESET resource in the FACILITY class.
> >Ensure that list-of-groups-checking (SETROPTS GRPLIST) is enabled.
> >
> >Perform the following steps to limit the authority of a general user 
> >or group to resume user IDs and reset passwords and password phrases 
> >based on the scope of a group tree.
> >
> >Define the following generic profiles in the FACILITY class, if 
> >not already defined. Doing so ensures that an existing generic 
> >profile does
> not
> >inadvertently prevent you from successfully limiting this authority.
> >Example:
> >
> >RDEFINE FACILITY IRR.PASSWORD.RESET.**  UACC(NONE)
> >RDEFINE FACILITY IRR.PWRESET.** UACC(NONE)
> >RDEFINE FACILITY IRR.PWRESET.EXCLUDE.** UACC(READ)
> >
> >If you use UPDATE or CONTROL access for any IRR.PWRESET profile, 
> >as described in Table 1, specify the higher level (UPDATE or CONTROL) 
> >with
> the
> >UACC operand for the IRR.PWRESET.EXCLUDE.** profile instead of the
> >UACC(READ) option shown in this example.
> >Define a profile to protect the IRR.PWRESET.TREE.owner resource 
> >in the FACILITY class, where owner is the group that is at the top of 
> >a group
> tree.
> >Example:
> >
> >RDEFINE FACILITY IRR.PWRESET.TREE.GROUP1 UACC(NONE)
> >   AUDIT(FAILURES(NONE) SUCCESSES(READ))
> >
> >
> >
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo
> s.v2r1
>
> >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_the_pass
> >word_fo
> >r_any_user.htm
> >
> >Steps for delegating the authority to reset the password for any user 
> >Perform the following steps to authorize a general user or group to 
> >use
> the
> >ALTUSER command to resume a revoked user or reset a user's password 
> >or password phrase.
> >
> >Define a profile to protect the IRR.PASSWORD.RESET resource in 
> >the FACILITY class.
> >Example:
> >
> >RDEFINE FACILITY IRR.PASSWORD.RESET UACC(NONE)
> >   AUDIT(FAILURES(NONE) SUCCESSES(READ))
> >
> >__
> >Authorize the general users or groups.
> >Example:
> >
> >PERMIT IRR.PASSWORD.RESET CLASS(FACILITY) ID(HELPDESK USER19)
> >ACCESS(READ)
> >
> >See Levels of authority for restrictions and details about 

Re: Keeping TSO users our of CICS

[Itschak Mugzach]

CICS does not require a CICS segment, so if you do not block the user at
the APPL, the default user CICS segment inherented to the user. Still don't
understand why the helpdesk users password authentication fails if it works
under TSO.

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Mon, Jul 27, 2020 at 11:57 PM Clark Morris  wrote:

> [Default] On 27 Jul 2020 13:40:48 -0700, in bit.listserv.ibm-main
> stars...@mindspring.com (Lizette Koehler) wrote:
>
> >First if you have not done so, you might want to join the CICS or RACF
> >Lists.
>
> While I am at least 20 years out of date, it used to be that someone
> had to be set up in each CICS region they were allowed to access.  So
> far as I know access to TSO does not automatically get you access to
> CICS and having access to CICS test does not mean access to CICS
> production or even CICS test for a different region.
>
> Clark Morris
> >
> >I think the IRR profiles can avoid the use of SPECIAL and OPERATIONS, but
> >you would need to research that
> >
> >
> >I think the RACF List may be more helpful
> >
> >CICS   http://www.listserv.uga.edu/archives/cics-l.html
> >RACF   http://www.listserv.uga.edu/archives/racf-l.html
> >
> >
> >Next I think here are IRR profiles that can be used to reset passwords.  I
> >am not very familiar with it, I think this
> >
> >
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
>
> >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_passwords_by_gr
> >oup_tree.htm
> >
> >
> >Steps for delegating the authority to reset passwords by group tree
> >
> >Before you begin:
> >
> >Make sure the ALTUSER command issuer does not have similar access to
> the
> >IRR.PASSWORD.RESET resource in the FACILITY class.
> >Ensure that list-of-groups-checking (SETROPTS GRPLIST) is enabled.
> >
> >Perform the following steps to limit the authority of a general user or
> >group to resume user IDs and reset passwords and password phrases based on
> >the scope of a group tree.
> >
> >Define the following generic profiles in the FACILITY class, if not
> >already defined. Doing so ensures that an existing generic profile does
> not
> >inadvertently prevent you from successfully limiting this authority.
> >Example:
> >
> >RDEFINE FACILITY IRR.PASSWORD.RESET.**  UACC(NONE)
> >RDEFINE FACILITY IRR.PWRESET.** UACC(NONE)
> >RDEFINE FACILITY IRR.PWRESET.EXCLUDE.** UACC(READ)
> >
> >If you use UPDATE or CONTROL access for any IRR.PWRESET profile, as
> >described in Table 1, specify the higher level (UPDATE or CONTROL) with
> the
> >UACC operand for the IRR.PWRESET.EXCLUDE.** profile instead of the
> >UACC(READ) option shown in this example.
> >Define a profile to protect the IRR.PWRESET.TREE.owner resource in the
> >FACILITY class, where owner is the group that is at the top of a group
> tree.
> >Example:
> >
> >RDEFINE FACILITY IRR.PWRESET.TREE.GROUP1 UACC(NONE)
> >   AUDIT(FAILURES(NONE) SUCCESSES(READ))
> >
> >
> >
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
>
> >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_the_password_fo
> >r_any_user.htm
> >
> >Steps for delegating the authority to reset the password for any user
> >Perform the following steps to authorize a general user or group to use
> the
> >ALTUSER command to resume a revoked user or reset a user's password or
> >password phrase.
> >
> >Define a profile to protect the IRR.PASSWORD.RESET resource in the
> >FACILITY class.
> >Example:
> >
> >RDEFINE FACILITY IRR.PASSWORD.RESET UACC(NONE)
> >   AUDIT(FAILURES(NONE) SUCCESSES(READ))
> >
> >__
> >Authorize the general users or groups.
> >Example:
> >
> >PERMIT IRR.PASSWORD.RESET CLASS(FACILITY) ID(HELPDESK USER19)
> >ACCESS(READ)
> >
> >See Levels of authority for restrictions and details about authority
> >based on the access level to IRR.PASSWORD.RESET.
> >
> >__
> >Activate the FACILITY class if not already active.
> >Example:
> >
> >SETROPTS CLASSACT(FACILITY)
> >
> >If the FACILITY class is already active and RACLISTed, refresh the
> >FACILITY class profiles.
> >
> >SETROPTS RACLIST(FACILITY) REFRESH
> >
> >__
> >
> >You have now authorized a general user or group to use the ALTUSER command
> >to resume the user ID or reset the password or password phrase for any
> user,
> >excluding protected users and users with the SPECIAL, OPERATION, or
> AUDITOR
> >attribute.
> >
> >
> >---

Re: OMVS CP command anomaly

[Itschak Mugzach]

what does it look like after copying from USS to PDS?

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Mon, Jul 27, 2020 at 11:50 PM Lionel B Dyck  wrote:

> Example of the issue:
>
> ISPF Panel code:
>
> )ATTR
>   0D TYPE(PS)
>   05 TYPE(PS)
> . . .
> )BODY
>
> Ideally would like a workstation IDE user to be able to view the data and
> perhaps update it and at some point return to z/OS for use.
>
>
> Lionel B. Dyck <
> Website: https://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
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Paul Gilmartin
> Sent: Monday, July 27, 2020 3:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: OMVS CP command anomaly
>
> On Mon, 27 Jul 2020 13:48:21 -0500, Lionel B Dyck wrote:
> >
> >Created several ISPF panels from DTL.  The result is an ISPF panel with
> >attribute characters that are binary (hex) with examples being x'01' ,
> >x'02', x'05, x'0D', and more.
> >
> >Copying these PDS members to an OMVS filesystem using cp works fine.
> >The data is NOT being copied as binary.
> >
> I'd prefer binary (cp -B) for data containing nondisplayable characters.
> >
> >The problem/anomaly is copying the files from OMVS into z/OS dataset
> >members results in these members being corrupted with the single record
> >being broken into one, or more, records.
> >
> >Example:  cp -A -U -v' rdir/*) "'"zos'"'
> >
> Which code points cause problems?
>
> Do you intend to manipulate (Edit, Browse, ...) the OMVS files?
>
> -- 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

GQSCAN vs ISGQUERY

[Tony Harminc]

The doc for GQSCAN says that "ISGQUERY is the recommended replacement for
the GQSCAN service". But it says nothing about GQSCAN being deprecated -
let alone eventually removed. We've used GQSCAN "forever" (actually since
July 2000), and I need to make some updates to the code that uses it. But
the interface to ISGQUERY is *very* different, looks much harder to use for
my purposes, and in particular does not return RIBs and RIBEs as does
GQSCAN.

So... Given that what I'm doing is a cross-system (SCOPE=SYSTEMS,XSYS=YES)
query on a QNAME/RNAME combo with the RNAME wildcarded:

Is there any clear advantage to converting to ISGQUERY?

Are there performance issues (beyond the general cost of the XSYS=YES)?
Given that ISGRIB comments say that the RIB/RIBE are copied from the GRS
private area to the user-supplied area, it would seem that this would
perform better than manufacturing the new-style return values from them,
*if* the RIB and RIBE are the underlying control blocks used within GRS.

Is there any serious chance that this use of GQSCAN will stop working in
future (yeah, I know - no commitment...)

The RIB and RIBE mappings in macro ISGRIB are classified PI. It's rare for
IBM to change these classifications, but it has happened. Any thoughts on
this?

Thanks.

Tony H.

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

Re: Keeping TSO users our of CICS

[Clark Morris]

[Default] On 27 Jul 2020 13:40:48 -0700, in bit.listserv.ibm-main
stars...@mindspring.com (Lizette Koehler) wrote:

>First if you have not done so, you might want to join the CICS or RACF
>Lists.  

While I am at least 20 years out of date, it used to be that someone
had to be set up in each CICS region they were allowed to access.  So
far as I know access to TSO does not automatically get you access to
CICS and having access to CICS test does not mean access to CICS
production or even CICS test for a different region.  

Clark Morris 
>
>I think the IRR profiles can avoid the use of SPECIAL and OPERATIONS, but
>you would need to research that
>
>
>I think the RACF List may be more helpful
>
>CICS   http://www.listserv.uga.edu/archives/cics-l.html
>RACF   http://www.listserv.uga.edu/archives/racf-l.html
>
>
>Next I think here are IRR profiles that can be used to reset passwords.  I
>am not very familiar with it, I think this
>
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
>.icha700/icha700_Steps_for_delegating_the_authority_to_reset_passwords_by_gr
>oup_tree.htm
>
>
>Steps for delegating the authority to reset passwords by group tree
>
>Before you begin:
>
>Make sure the ALTUSER command issuer does not have similar access to the
>IRR.PASSWORD.RESET resource in the FACILITY class.
>Ensure that list-of-groups-checking (SETROPTS GRPLIST) is enabled.
>
>Perform the following steps to limit the authority of a general user or
>group to resume user IDs and reset passwords and password phrases based on
>the scope of a group tree.
>
>Define the following generic profiles in the FACILITY class, if not
>already defined. Doing so ensures that an existing generic profile does not
>inadvertently prevent you from successfully limiting this authority.
>Example:
>
>RDEFINE FACILITY IRR.PASSWORD.RESET.**  UACC(NONE)
>RDEFINE FACILITY IRR.PWRESET.** UACC(NONE)
>RDEFINE FACILITY IRR.PWRESET.EXCLUDE.** UACC(READ)
>
>If you use UPDATE or CONTROL access for any IRR.PWRESET profile, as
>described in Table 1, specify the higher level (UPDATE or CONTROL) with the
>UACC operand for the IRR.PWRESET.EXCLUDE.** profile instead of the
>UACC(READ) option shown in this example.
>Define a profile to protect the IRR.PWRESET.TREE.owner resource in the
>FACILITY class, where owner is the group that is at the top of a group tree.
>Example:
>
>RDEFINE FACILITY IRR.PWRESET.TREE.GROUP1 UACC(NONE)
>   AUDIT(FAILURES(NONE) SUCCESSES(READ))
>
>
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
>.icha700/icha700_Steps_for_delegating_the_authority_to_reset_the_password_fo
>r_any_user.htm
>
>Steps for delegating the authority to reset the password for any user
>Perform the following steps to authorize a general user or group to use the
>ALTUSER command to resume a revoked user or reset a user's password or
>password phrase.
>
>Define a profile to protect the IRR.PASSWORD.RESET resource in the
>FACILITY class.
>Example:
>
>RDEFINE FACILITY IRR.PASSWORD.RESET UACC(NONE)
>   AUDIT(FAILURES(NONE) SUCCESSES(READ))
>
>__
>Authorize the general users or groups.
>Example:
>
>PERMIT IRR.PASSWORD.RESET CLASS(FACILITY) ID(HELPDESK USER19)
>ACCESS(READ) 
>
>See Levels of authority for restrictions and details about authority
>based on the access level to IRR.PASSWORD.RESET.
>
>__
>Activate the FACILITY class if not already active.
>Example:
>
>SETROPTS CLASSACT(FACILITY) 
>
>If the FACILITY class is already active and RACLISTed, refresh the
>FACILITY class profiles.
>
>SETROPTS RACLIST(FACILITY) REFRESH
>
>__
>
>You have now authorized a general user or group to use the ALTUSER command
>to resume the user ID or reset the password or password phrase for any user,
>excluding protected users and users with the SPECIAL, OPERATION, or AUDITOR
>attribute.
>
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of
>McCabe, Ron
>Sent: Monday, July 27, 2020 1:32 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Keeping TSO users our of CICS
>
>Hello IBM Listers,
>
>Got an interesting problem that I would like to know how we can avoid.  Our
>Help Desk users TSO accounts have the SPECIAL ATTRIBUTE so they can reset
>passwords and define new users.  These TSO accounts are not defined to CICS
>but every once in awhile one of them will try to login to CICS using their
>TSO account and after messing up their password 3 times the system puts out
>an ICH302D message asking if we want to REVOKE them or let them try again
>(we REVOKE), this message waits for a reply and while it is waiting CICS
>hangs until a reply is given.  We thought about defining their TSO accounts
>to CICS but that d

Re: Keeping TSO users our of CICS

[ITschak Mugzach]

How about appl class? If the user is not authorized to the cics applid, he
can't login.

Btw, why (and how) is their password different on cics? If racf recognize
they have the  special attribute, it seems this is the same racf...

ITschak


ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM comming son  *




On Mon, Jul 27, 2020 at 11:49 PM Itschak Mugzach 
wrote:

> How about appl class? If the user is not authorized to the cics applid, he
> can't login.
>
> Btw, why (and how) is their password different on cics? If racf recognize
> they have the  special attribute, it seems this is the same racf...
>
> ITschak
>
>
> בתאריך יום ב׳, 27 ביולי 2020, 23:40, מאת Lizette Koehler ‏<
> stars...@mindspring.com>:
>
>> First if you have not done so, you might want to join the CICS or RACF
>> Lists.
>>
>> I think the IRR profiles can avoid the use of SPECIAL and OPERATIONS, but
>> you would need to research that
>>
>>
>> I think the RACF List may be more helpful
>>
>> CICShttp://www.listserv.uga.edu/archives/cics-l.html
>> RACFhttp://www.listserv.uga.edu/archives/racf-l.html
>>
>>
>> Next I think here are IRR profiles that can be used to reset passwords.  I
>> am not very familiar with it, I think this
>>
>>
>> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
>>
>> .icha700/icha700_Steps_for_delegating_the_authority_to_reset_passwords_by_gr
>> oup_tree.htm
>>
>>
>> Steps for delegating the authority to reset passwords by group tree
>>
>> Before you begin:
>>
>> Make sure the ALTUSER command issuer does not have similar access to
>> the
>> IRR.PASSWORD.RESET resource in the FACILITY class.
>> Ensure that list-of-groups-checking (SETROPTS GRPLIST) is enabled.
>>
>> Perform the following steps to limit the authority of a general user or
>> group to resume user IDs and reset passwords and password phrases based on
>> the scope of a group tree.
>>
>> Define the following generic profiles in the FACILITY class, if not
>> already defined. Doing so ensures that an existing generic profile does
>> not
>> inadvertently prevent you from successfully limiting this authority.
>> Example:
>>
>> RDEFINE FACILITY IRR.PASSWORD.RESET.**  UACC(NONE)
>> RDEFINE FACILITY IRR.PWRESET.** UACC(NONE)
>> RDEFINE FACILITY IRR.PWRESET.EXCLUDE.** UACC(READ)
>>
>> If you use UPDATE or CONTROL access for any IRR.PWRESET profile, as
>> described in Table 1, specify the higher level (UPDATE or CONTROL) with
>> the
>> UACC operand for the IRR.PWRESET.EXCLUDE.** profile instead of the
>> UACC(READ) option shown in this example.
>> Define a profile to protect the IRR.PWRESET.TREE.owner resource in the
>> FACILITY class, where owner is the group that is at the top of a group
>> tree.
>> Example:
>>
>> RDEFINE FACILITY IRR.PWRESET.TREE.GROUP1 UACC(NONE)
>>AUDIT(FAILURES(NONE) SUCCESSES(READ))
>>
>>
>>
>> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
>>
>> .icha700/icha700_Steps_for_delegating_the_authority_to_reset_the_password_fo
>> r_any_user.htm
>>
>> Steps for delegating the authority to reset the password for any user
>> Perform the following steps to authorize a general user or group to use
>> the
>> ALTUSER command to resume a revoked user or reset a user's password or
>> password phrase.
>>
>> Define a profile to protect the IRR.PASSWORD.RESET resource in the
>> FACILITY class.
>> Example:
>>
>> RDEFINE FACILITY IRR.PASSWORD.RESET UACC(NONE)
>>AUDIT(FAILURES(NONE) SUCCESSES(READ))
>>
>> __
>> Authorize the general users or groups.
>> Example:
>>
>> PERMIT IRR.PASSWORD.RESET CLASS(FACILITY) ID(HELPDESK USER19)
>> ACCESS(READ)
>>
>> See Levels of authority for restrictions and details about authority
>> based on the access level to IRR.PASSWORD.RESET.
>>
>> __
>> Activate the FACILITY class if not already active.
>> Example:
>>
>> SETROPTS CLASSACT(FACILITY)
>>
>> If the FACILITY class is already active and RACLISTed, refresh the
>> FACILITY class profiles.
>>
>> SETROPTS RACLIST(FACILITY) REFRESH
>>
>> __
>>
>> You have now authorized a general user or group to use the ALTUSER command
>> to resume the user ID or reset the password or password phrase for any
>> user,
>> excluding protected users and users with the SPECIAL, OPERATION, or
>> AUDITOR
>> attribute.
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf
>> Of
>> McCabe, Ron
>> Sent: Monday, July 27, 2020 1:32 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Keeping TSO users our of CICS
>>
>> Hello IBM Listers,
>>
>> Got an interesting problem that I would like to know how we can avoid.
>> Ou

Re: OMVS CP command anomaly

[Lionel B Dyck]

Example of the issue:

ISPF Panel code:

)ATTR
  0D TYPE(PS)
  05 TYPE(PS)
. . .
)BODY

Ideally would like a workstation IDE user to be able to view the data and 
perhaps update it and at some point return to z/OS for use.


Lionel B. Dyck <
Website: https://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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Monday, July 27, 2020 3:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OMVS CP command anomaly

On Mon, 27 Jul 2020 13:48:21 -0500, Lionel B Dyck wrote:
>
>Created several ISPF panels from DTL.  The result is an ISPF panel with 
>attribute characters that are binary (hex) with examples being x'01' , 
>x'02', x'05, x'0D', and more.
>
>Copying these PDS members to an OMVS filesystem using cp works fine.  
>The data is NOT being copied as binary.
> 
I'd prefer binary (cp -B) for data containing nondisplayable characters.
>
>The problem/anomaly is copying the files from OMVS into z/OS dataset 
>members results in these members being corrupted with the single record  
>being broken into one, or more, records.
>
>Example:  cp -A -U -v' rdir/*) "'"zos'"'
>
Which code points cause problems?

Do you intend to manipulate (Edit, Browse, ...) the OMVS files?

-- 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: Keeping TSO users our of CICS

[Itschak Mugzach]

How about appl class? If the user is not authorized to the cics applid, he
can't login.

Btw, why (and how) is their password different on cics? If racf recognize
they have the  special attribute, it seems this is the same racf...

ITschak


בתאריך יום ב׳, 27 ביולי 2020, 23:40, מאת Lizette Koehler ‏<
stars...@mindspring.com>:

> First if you have not done so, you might want to join the CICS or RACF
> Lists.
>
> I think the IRR profiles can avoid the use of SPECIAL and OPERATIONS, but
> you would need to research that
>
>
> I think the RACF List may be more helpful
>
> CICShttp://www.listserv.uga.edu/archives/cics-l.html
> RACFhttp://www.listserv.uga.edu/archives/racf-l.html
>
>
> Next I think here are IRR profiles that can be used to reset passwords.  I
> am not very familiar with it, I think this
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
>
> .icha700/icha700_Steps_for_delegating_the_authority_to_reset_passwords_by_gr
> oup_tree.htm
>
>
> Steps for delegating the authority to reset passwords by group tree
>
> Before you begin:
>
> Make sure the ALTUSER command issuer does not have similar access to
> the
> IRR.PASSWORD.RESET resource in the FACILITY class.
> Ensure that list-of-groups-checking (SETROPTS GRPLIST) is enabled.
>
> Perform the following steps to limit the authority of a general user or
> group to resume user IDs and reset passwords and password phrases based on
> the scope of a group tree.
>
> Define the following generic profiles in the FACILITY class, if not
> already defined. Doing so ensures that an existing generic profile does not
> inadvertently prevent you from successfully limiting this authority.
> Example:
>
> RDEFINE FACILITY IRR.PASSWORD.RESET.**  UACC(NONE)
> RDEFINE FACILITY IRR.PWRESET.** UACC(NONE)
> RDEFINE FACILITY IRR.PWRESET.EXCLUDE.** UACC(READ)
>
> If you use UPDATE or CONTROL access for any IRR.PWRESET profile, as
> described in Table 1, specify the higher level (UPDATE or CONTROL) with the
> UACC operand for the IRR.PWRESET.EXCLUDE.** profile instead of the
> UACC(READ) option shown in this example.
> Define a profile to protect the IRR.PWRESET.TREE.owner resource in the
> FACILITY class, where owner is the group that is at the top of a group
> tree.
> Example:
>
> RDEFINE FACILITY IRR.PWRESET.TREE.GROUP1 UACC(NONE)
>AUDIT(FAILURES(NONE) SUCCESSES(READ))
>
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
>
> .icha700/icha700_Steps_for_delegating_the_authority_to_reset_the_password_fo
> r_any_user.htm
>
> Steps for delegating the authority to reset the password for any user
> Perform the following steps to authorize a general user or group to use the
> ALTUSER command to resume a revoked user or reset a user's password or
> password phrase.
>
> Define a profile to protect the IRR.PASSWORD.RESET resource in the
> FACILITY class.
> Example:
>
> RDEFINE FACILITY IRR.PASSWORD.RESET UACC(NONE)
>AUDIT(FAILURES(NONE) SUCCESSES(READ))
>
> __
> Authorize the general users or groups.
> Example:
>
> PERMIT IRR.PASSWORD.RESET CLASS(FACILITY) ID(HELPDESK USER19)
> ACCESS(READ)
>
> See Levels of authority for restrictions and details about authority
> based on the access level to IRR.PASSWORD.RESET.
>
> __
> Activate the FACILITY class if not already active.
> Example:
>
> SETROPTS CLASSACT(FACILITY)
>
> If the FACILITY class is already active and RACLISTed, refresh the
> FACILITY class profiles.
>
> SETROPTS RACLIST(FACILITY) REFRESH
>
> __
>
> You have now authorized a general user or group to use the ALTUSER command
> to resume the user ID or reset the password or password phrase for any
> user,
> excluding protected users and users with the SPECIAL, OPERATION, or AUDITOR
> attribute.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of
> McCabe, Ron
> Sent: Monday, July 27, 2020 1:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Keeping TSO users our of CICS
>
> Hello IBM Listers,
>
> Got an interesting problem that I would like to know how we can avoid.  Our
> Help Desk users TSO accounts have the SPECIAL ATTRIBUTE so they can reset
> passwords and define new users.  These TSO accounts are not defined to CICS
> but every once in awhile one of them will try to login to CICS using their
> TSO account and after messing up their password 3 times the system puts out
> an ICH302D message asking if we want to REVOKE them or let them try again
> (we REVOKE), this message waits for a reply and while it is waiting CICS
> hangs until a reply is given.  We thought about defining their TSO accounts
> to CICS but that does not help if they actually do m

Re: Keeping TSO users our of CICS

[Lizette Koehler]

First if you have not done so, you might want to join the CICS or RACF
Lists.  

I think the IRR profiles can avoid the use of SPECIAL and OPERATIONS, but
you would need to research that


I think the RACF List may be more helpful

CICShttp://www.listserv.uga.edu/archives/cics-l.html
RACFhttp://www.listserv.uga.edu/archives/racf-l.html


Next I think here are IRR profiles that can be used to reset passwords.  I
am not very familiar with it, I think this

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
.icha700/icha700_Steps_for_delegating_the_authority_to_reset_passwords_by_gr
oup_tree.htm


Steps for delegating the authority to reset passwords by group tree

Before you begin:

Make sure the ALTUSER command issuer does not have similar access to the
IRR.PASSWORD.RESET resource in the FACILITY class.
Ensure that list-of-groups-checking (SETROPTS GRPLIST) is enabled.

Perform the following steps to limit the authority of a general user or
group to resume user IDs and reset passwords and password phrases based on
the scope of a group tree.

Define the following generic profiles in the FACILITY class, if not
already defined. Doing so ensures that an existing generic profile does not
inadvertently prevent you from successfully limiting this authority.
Example:

RDEFINE FACILITY IRR.PASSWORD.RESET.**  UACC(NONE)
RDEFINE FACILITY IRR.PWRESET.** UACC(NONE)
RDEFINE FACILITY IRR.PWRESET.EXCLUDE.** UACC(READ)

If you use UPDATE or CONTROL access for any IRR.PWRESET profile, as
described in Table 1, specify the higher level (UPDATE or CONTROL) with the
UACC operand for the IRR.PWRESET.EXCLUDE.** profile instead of the
UACC(READ) option shown in this example.
Define a profile to protect the IRR.PWRESET.TREE.owner resource in the
FACILITY class, where owner is the group that is at the top of a group tree.
Example:

RDEFINE FACILITY IRR.PWRESET.TREE.GROUP1 UACC(NONE)
   AUDIT(FAILURES(NONE) SUCCESSES(READ))


https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1
.icha700/icha700_Steps_for_delegating_the_authority_to_reset_the_password_fo
r_any_user.htm

Steps for delegating the authority to reset the password for any user
Perform the following steps to authorize a general user or group to use the
ALTUSER command to resume a revoked user or reset a user's password or
password phrase.

Define a profile to protect the IRR.PASSWORD.RESET resource in the
FACILITY class.
Example:

RDEFINE FACILITY IRR.PASSWORD.RESET UACC(NONE)
   AUDIT(FAILURES(NONE) SUCCESSES(READ))

__
Authorize the general users or groups.
Example:

PERMIT IRR.PASSWORD.RESET CLASS(FACILITY) ID(HELPDESK USER19)
ACCESS(READ) 

See Levels of authority for restrictions and details about authority
based on the access level to IRR.PASSWORD.RESET.

__
Activate the FACILITY class if not already active.
Example:

SETROPTS CLASSACT(FACILITY) 

If the FACILITY class is already active and RACLISTed, refresh the
FACILITY class profiles.

SETROPTS RACLIST(FACILITY) REFRESH

__

You have now authorized a general user or group to use the ALTUSER command
to resume the user ID or reset the password or password phrase for any user,
excluding protected users and users with the SPECIAL, OPERATION, or AUDITOR
attribute.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
McCabe, Ron
Sent: Monday, July 27, 2020 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Keeping TSO users our of CICS

Hello IBM Listers,

Got an interesting problem that I would like to know how we can avoid.  Our
Help Desk users TSO accounts have the SPECIAL ATTRIBUTE so they can reset
passwords and define new users.  These TSO accounts are not defined to CICS
but every once in awhile one of them will try to login to CICS using their
TSO account and after messing up their password 3 times the system puts out
an ICH302D message asking if we want to REVOKE them or let them try again
(we REVOKE), this message waits for a reply and while it is waiting CICS
hangs until a reply is given.  We thought about defining their TSO accounts
to CICS but that does not help if they actually do mess up their password.
We thought we could do it with RACF but RACF doesn't check any authorization
until "after" the user successfully signs on so we would still get the
ICH302D message.

Does anyone else run into this problem?  Is there a way we can get around
this problem?  We thought about having MSGTABLE do an automated response but
there could be times when we don't want to have the user REVOKED.

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments

Re: OMVS CP command anomaly

[Paul Gilmartin]

On Mon, 27 Jul 2020 13:48:21 -0500, Lionel B Dyck wrote:
>
>Created several ISPF panels from DTL.  The result is an ISPF panel with
>attribute characters that are binary (hex) with examples being x'01' ,
>x'02', x'05, x'0D', and more.
>
>Copying these PDS members to an OMVS filesystem using cp works fine.  The
>data is NOT being copied as binary.
> 
I'd prefer binary (cp -B) for data containing nondisplayable characters.
>
>The problem/anomaly is copying the files from OMVS into z/OS dataset members
>results in these members being corrupted with the single record  being
>broken into one, or more, records. 
>
>Example:  cp -A -U -v' rdir/*) "'"zos'"'
>
Which code points cause problems?

Do you intend to manipulate (Edit, Browse, ...) the OMVS files?

-- gil

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

Re: EXTERNAL EMAIL: Keeping TSO users our of CICS

[Jerry Whitteridge]

This might be a case of using the RACF VTAMAPPL class and only granting access 
to your helpdesk folks to the TSO APPL's and not the CICS Appls.
You'd get more expert advice from the RACF-L if you wanted

Jerry Whitteridge
jerry.whitteri...@albertsons.com
Manager Mainframe Systems & HP Non-Stop
Albertsons Companies

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
McCabe, Ron
Sent: Monday, July 27, 2020 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL EMAIL: Keeping TSO users our of CICS

Hello IBM Listers,

Got an interesting problem that I would like to know how we can avoid.  Our 
Help Desk users TSO accounts have the SPECIAL ATTRIBUTE so they can reset 
passwords and define new users.  These TSO accounts are not defined to CICS but 
every once in awhile one of them will try to login to CICS using their TSO 
account and after messing up their password 3 times the system puts out an 
ICH302D message asking if we want to REVOKE them or let them try again (we 
REVOKE), this message waits for a reply and while it is waiting CICS hangs 
until a reply is given.  We thought about defining their TSO accounts to CICS 
but that does not help if they actually do mess up their password.  We thought 
we could do it with RACF but RACF doesn't check any authorization until "after" 
the user successfully signs on so we would still get the ICH302D message.

Does anyone else run into this problem?  Is there a way we can get around this 
problem?  We thought about having MSGTABLE do an automated response but there 
could be times when we don't want to have the user REVOKED.

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

Keeping TSO users our of CICS

[McCabe, Ron]

Hello IBM Listers,

Got an interesting problem that I would like to know how we can avoid.  Our 
Help Desk users TSO accounts have the SPECIAL ATTRIBUTE so they can reset 
passwords and define new users.  These TSO accounts are not defined to CICS but 
every once in awhile one of them will try to login to CICS using their TSO 
account and after messing up their password 3 times the system puts out an 
ICH302D message asking if we want to REVOKE them or let them try again (we 
REVOKE), this message waits for a reply and while it is waiting CICS hangs 
until a reply is given.  We thought about defining their TSO accounts to CICS 
but that does not help if they actually do mess up their password.  We thought 
we could do it with RACF but RACF doesn't check any authorization until "after" 
the user successfully signs on so we would still get the ICH302D message.

Does anyone else run into this problem?  Is there a way we can get around this 
problem?  We thought about having MSGTABLE do an automated response but there 
could be times when we don't want to have the user REVOKED.

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

Re: Where is the data compression manual SA22-7208

[Sri h Kolusu]

John,

I tried sending you the PDF version of the manual via offline message, but
looks like your email address is not accepting them.   If you want a copy
of the pdf then email me directly.

Thanks.
Kolusu

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

OMVS CP command anomaly

[Lionel B Dyck]

Here is the anomaly.  

 

Created several ISPF panels from DTL.  The result is an ISPF panel with
attribute characters that are binary (hex) with examples being x'01' ,
x'02', x'05, x'0D', and more.

 

Copying these PDS members to an OMVS filesystem using cp works fine.  The
data is NOT being copied as binary.

 

The problem/anomaly is copying the files from OMVS into z/OS dataset members
results in these members being corrupted with the single record  being
broken into one, or more, records.

 

Example:  cp -A -U -v' rdir/*) "'"zos'"'  

 

Any advice?

 

Thanks

 

Lionel B. Dyck <
Website:   https://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: Diskcopy Error During Backup Operation

[Edward Finnell]

Place a service call. Show them the EREP output from the window of IOS messages.

In a message dated 7/27/2020 10:12:21 AM Central Standard Time, 
burha...@maintec.in writes:
During the copy operation, we are receiving the following errors for certain 
volumes however the job runs successfully with MAXCC=0

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

Re: Started task stopping immediately. No error messages.

[Lennie Dymoke-Bradshaw]

SDSF has supported JES3 since z/OS 1.10. 

Lennie Dymoke-Bradshaw
'Dance like no one is watching. Encrypt like everyone is.'

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: 27 July 2020 16:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Started task stopping immediately. No error messages.

It looks like you're using JES3. I thought thad SDSF didn't support it.

CC 0 would have been a useful datum in the original question. It looks like the 
FTP server doesn't issue an informational message when a copy is already 
running. RFE?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Skippy the Ancient [kkin...@email.com]
Sent: Monday, July 27, 2020 8:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Started task stopping immediately. No error messages.

Responding to all posters, not just Mr Metz.

1. I already tried calling the proc from JCL.  It ran, stopped immediately and 
returned no error messages.
2. I started the proc with the MSGCLASS and did receive output.  It was 
identical to the JCL call; immediate stop and no error messages.  I will post 
this below.
3. The started task is a second FTP server supporting FTPS. To simplify, I 
copied the FTPD proc and renamed it FTPSD.  In theory, it is running exactly as 
the original FTPD task with a different port. (990) 4. The PROFILE update reads 
like this - AUTOLOG
   FTPSD JOBNAME FTPSD  ; FTPS SERVER
ENDAUTOLOG
PORT
   989 TCP OMVS; FTPS SERVER
   990 TCP FTPSD NOAUTOLOG ; FTPS SERVER

Here is the output of running the started task - (system specifics changed for 
security reasons)
 08:26:31  IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB  DSN=SYSX.TCPIP.SEZATCP
 08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB  DSN=SYSX.TCPIP.XXLOAD
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSFTPD  DSN=SYSX.TCPIP.PARMLIB
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSTCPD  DSN=SYSX.TCPIP.PARMLIB
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31  IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER 
FTPSD   , GROUP 
 08:26:31  ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD
 08:26:31  IEF403I FTPSD - STARTED - TIME=08.26.31
 08:26:31  IEF404I FTPSD - ENDED - TIME=08.26.31
//FTPSDJOB MSGCLASS=T, *
// MSGLEVEL=1
//STARTING EXEC FTPSD
1 //FTPSDJOB MSGCLASS=T,
 *
  // MSGLEVEL=1
2 //STARTING EXEC FTPSD
3 XXFTPSD  PROC MODULE='FTPD',PARMS='TRACE PORT 990'
4 XXFTPD   EXEC PGM=&MODULE,REGION=0M,TIME=NOLIMIT,
  XX  PARM='POSIX(ON) ALL31(ON)/&PARMS'
  IEFC653I SUBSTITUTION JCL - 
PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'
5 XXSTEPLIB  DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR
6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR
7 XXCEEDUMP  DD SYSOUT=*
8 XXSYSOUT   DD SYSOUT=*
9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL)
   10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA)
 STMT NO. MESSAGE
2 IEFC001I PROCEDURE FTPSD WAS EXPANDED USING SYSTEM LIBRARY 
SYSX.PROCLIB
IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD   , 
GROUP USSGRPX
IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002 IEF142I FTPSD 
FTPSD - STEP WAS EXECUTED - COND CODE 
IEF373I STEP/FTPD/START 2020209.0826
IEF032I STEP/FTPD/STOP  2020209.0826
CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC
VIRT:80K  SYS:   216K  EXT: 2220K  SYS: 9108K
ATB- REAL:12K  SLOTS: 0K
 VIRT- ALLOC:   7M SHRD:   0M
IEF375I  JOB/FTPSD   /START 2020209.0826
IEF033I  JOB/FTPSD   /STOP  2020209.0826
CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC

--
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: Started task stopping immediately. No error messages.

[Gibney, Dave]

Possibly some info in syslogd

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Seymour J Metz
> Sent: Monday, July 27, 2020 8:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Started task stopping immediately. No error messages.
> 
> It looks like you're using JES3. I thought thad SDSF didn't support it.
> 
> CC 0 would have been a useful datum in the original question. It looks like 
> the
> FTP server doesn't issue an informational message when a copy is already
> running. RFE?
> 
> 
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY0HMszNaDT!7xDq6muI8JTtv3mmwg6UqC942wokzRIymdbjmWB_ZQre96Lf
> VaVgDchI02em-w$
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Skippy the Ancient [kkin...@email.com]
> Sent: Monday, July 27, 2020 8:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Started task stopping immediately. No error messages.
> 
> Responding to all posters, not just Mr Metz.
> 
> 1. I already tried calling the proc from JCL.  It ran, stopped immediately and
> returned no error messages.
> 2. I started the proc with the MSGCLASS and did receive output.  It was
> identical to the JCL call; immediate stop and no error messages.  I will post
> this below.
> 3. The started task is a second FTP server supporting FTPS. To simplify, I
> copied the FTPD proc and renamed it FTPSD.  In theory, it is running exactly
> as the original FTPD task with a different port. (990)
> 4. The PROFILE update reads like this -
> AUTOLOG
>FTPSD JOBNAME FTPSD  ; FTPS SERVER
> ENDAUTOLOG
> PORT
>989 TCP OMVS; FTPS SERVER
>990 TCP FTPSD NOAUTOLOG ; FTPS SERVER
> 
> Here is the output of running the started task - (system specifics changed for
> security reasons)
>  08:26:31  IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB
> DSN=SYSX.TCPIP.SEZATCP
>  08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB
> DSN=SYSX.TCPIP.XXLOAD
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSFTPD
> DSN=SYSX.TCPIP.PARMLIB
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSTCPD
> DSN=SYSX.TCPIP.PARMLIB
>  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
>  08:26:31  IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO
> USER FTPSD   , GROUP 
>  08:26:31  ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD
>  08:26:31  IEF403I FTPSD - STARTED - TIME=08.26.31
>  08:26:31  IEF404I FTPSD - ENDED - TIME=08.26.31
> //FTPSDJOB MSGCLASS=T, *
> // MSGLEVEL=1
> //STARTING EXEC FTPSD
> 1 //FTPSDJOB MSGCLASS=T,  
>*
>   // MSGLEVEL=1
> 2 //STARTING EXEC FTPSD
> 3 XXFTPSD  PROC MODULE='FTPD',PARMS='TRACE PORT 990'
> 4 XXFTPD   EXEC PGM=&MODULE,REGION=0M,TIME=NOLIMIT,
>   XX  PARM='POSIX(ON) ALL31(ON)/&PARMS'
>   IEFC653I SUBSTITUTION JCL -
> PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON)
> ALL31(ON)/TRACE PORT 990'
> 5 XXSTEPLIB  DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR
> 6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR
> 7 XXCEEDUMP  DD SYSOUT=*
> 8 XXSYSOUT   DD SYSOUT=*
> 9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL)
>10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA)
>  STMT NO. MESSAGE
> 2 IEFC001I PROCEDURE FTPSD WAS EXPANDED USING SYSTEM LIBRARY
> SYSX.PROCLIB
> IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD
> , GROUP USSGRPX
> IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
> Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002
> IEF142I FTPSD FTPSD - STEP WAS EXECUTED - COND CODE 
> IEF373I STEP/FTPD/START 2020209.0826
> IEF032I STEP/FTPD/STOP  2020209.0826
> CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC
> VIRT:80K  SYS:   216K  EXT: 2220K  SYS: 9108K
> ATB- REAL:12K  SLOTS: 0K
>  VIRT- ALLOC:   7M SHRD:   0M
> IEF375I  JOB/FTPSD   /START 2020209.0826
> IEF033I  JOB/FTPSD   /STOP  2020209.0826
> CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC
> 
> --
> 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: Started task stopping immediately. No error messages.

[David Spiegel]

Hi R'Shmuel AMV"SH,
Please see: http://www.redbooks.ibm.com/redpapers/pdfs/redp4531.pdf

Regards,
David

On 2020-07-27 11:31, Seymour J Metz wrote:

It looks like you're using JES3. I thought thad SDSF didn't support it.

CC 0 would have been a useful datum in the original question. It looks like the 
FTP server doesn't issue an informational message when a copy is already 
running. RFE?


--
Shmuel (Seymour J.) Metz
https://eur05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7C6021693a92ca4c144c2f08d832421f55%7C84df9e7fe9f640afb435%7C1%7C0%7C637314606868155889&sdata=IL9519W%2FFddRjKEIuP9cn1z4JEz2HND1JmVk%2BVWpNn4%3D&reserved=0


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Skippy the Ancient [kkin...@email.com]
Sent: Monday, July 27, 2020 8:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Started task stopping immediately. No error messages.

Responding to all posters, not just Mr Metz.

1. I already tried calling the proc from JCL.  It ran, stopped immediately and 
returned no error messages.
2. I started the proc with the MSGCLASS and did receive output.  It was 
identical to the JCL call; immediate stop and no error messages.  I will post 
this below.
3. The started task is a second FTP server supporting FTPS. To simplify, I 
copied the FTPD proc and renamed it FTPSD.  In theory, it is running exactly as 
the original FTPD task with a different port. (990)
4. The PROFILE update reads like this -
AUTOLOG
FTPSD JOBNAME FTPSD  ; FTPS SERVER
ENDAUTOLOG
PORT
989 TCP OMVS; FTPS SERVER
990 TCP FTPSD NOAUTOLOG ; FTPS SERVER

Here is the output of running the started task - (system specifics changed for 
security reasons)
  08:26:31  IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 
  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB  DSN=SYSX.TCPIP.SEZATCP
  08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY
  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB  DSN=SYSX.TCPIP.XXLOAD
  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSFTPD  DSN=SYSX.TCPIP.PARMLIB
  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSTCPD  DSN=SYSX.TCPIP.PARMLIB
  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
  08:26:31  IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER 
FTPSD   , GROUP 
  08:26:31  ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD
  08:26:31  IEF403I FTPSD - STARTED - TIME=08.26.31
  08:26:31  IEF404I FTPSD - ENDED - TIME=08.26.31
//FTPSDJOB MSGCLASS=T, *
// MSGLEVEL=1
//STARTING EXEC FTPSD
 1 //FTPSDJOB MSGCLASS=T,   
  *
   // MSGLEVEL=1
 2 //STARTING EXEC FTPSD
 3 XXFTPSD  PROC MODULE='FTPD',PARMS='TRACE PORT 990'
 4 XXFTPD   EXEC PGM=&MODULE,REGION=0M,TIME=NOLIMIT,
   XX  PARM='POSIX(ON) ALL31(ON)/&PARMS'
   IEFC653I SUBSTITUTION JCL - 
PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'
 5 XXSTEPLIB  DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR
 6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR
 7 XXCEEDUMP  DD SYSOUT=*
 8 XXSYSOUT   DD SYSOUT=*
 9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL)
10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA)
  STMT NO. MESSAGE
 2 IEFC001I PROCEDURE FTPSD WAS EXPANDED USING SYSTEM LIBRARY 
SYSX.PROCLIB
IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD   , 
GROUP USSGRPX
IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
 Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002
IEF142I FTPSD FTPSD - STEP WAS EXECUTED - COND CODE 
IEF373I STEP/FTPD/START 2020209.0826
IEF032I STEP/FTPD/STOP  2020209.0826
 CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC
 VIRT:80K  SYS:   216K  EXT: 2220K  SYS: 9108K
 ATB- REAL:12K  SLOTS: 0K
  VIRT- ALLOC:   7M SHRD:   0M
IEF375I  JOB/FTPSD   /START 2020209.0826
IEF033I  JOB/FTPSD   /STOP  2020209.0826
 CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC

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

Re: Started task stopping immediately. No error messages.

[Seymour J Metz]

It looks like you're using JES3. I thought thad SDSF didn't support it.

CC 0 would have been a useful datum in the original question. It looks like the 
FTP server doesn't issue an informational message when a copy is already 
running. RFE?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Skippy the Ancient [kkin...@email.com]
Sent: Monday, July 27, 2020 8:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Started task stopping immediately. No error messages.

Responding to all posters, not just Mr Metz.

1. I already tried calling the proc from JCL.  It ran, stopped immediately and 
returned no error messages.
2. I started the proc with the MSGCLASS and did receive output.  It was 
identical to the JCL call; immediate stop and no error messages.  I will post 
this below.
3. The started task is a second FTP server supporting FTPS. To simplify, I 
copied the FTPD proc and renamed it FTPSD.  In theory, it is running exactly as 
the original FTPD task with a different port. (990)
4. The PROFILE update reads like this -
AUTOLOG
   FTPSD JOBNAME FTPSD  ; FTPS SERVER
ENDAUTOLOG
PORT
   989 TCP OMVS; FTPS SERVER
   990 TCP FTPSD NOAUTOLOG ; FTPS SERVER

Here is the output of running the started task - (system specifics changed for 
security reasons)
 08:26:31  IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB  DSN=SYSX.TCPIP.SEZATCP
 08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB  DSN=SYSX.TCPIP.XXLOAD
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSFTPD  DSN=SYSX.TCPIP.PARMLIB
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSTCPD  DSN=SYSX.TCPIP.PARMLIB
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31  IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER 
FTPSD   , GROUP 
 08:26:31  ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD
 08:26:31  IEF403I FTPSD - STARTED - TIME=08.26.31
 08:26:31  IEF404I FTPSD - ENDED - TIME=08.26.31
//FTPSDJOB MSGCLASS=T, *
// MSGLEVEL=1
//STARTING EXEC FTPSD
1 //FTPSDJOB MSGCLASS=T,
 *
  // MSGLEVEL=1
2 //STARTING EXEC FTPSD
3 XXFTPSD  PROC MODULE='FTPD',PARMS='TRACE PORT 990'
4 XXFTPD   EXEC PGM=&MODULE,REGION=0M,TIME=NOLIMIT,
  XX  PARM='POSIX(ON) ALL31(ON)/&PARMS'
  IEFC653I SUBSTITUTION JCL - 
PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'
5 XXSTEPLIB  DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR
6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR
7 XXCEEDUMP  DD SYSOUT=*
8 XXSYSOUT   DD SYSOUT=*
9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL)
   10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA)
 STMT NO. MESSAGE
2 IEFC001I PROCEDURE FTPSD WAS EXPANDED USING SYSTEM LIBRARY 
SYSX.PROCLIB
IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD   , 
GROUP USSGRPX
IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002
IEF142I FTPSD FTPSD - STEP WAS EXECUTED - COND CODE 
IEF373I STEP/FTPD/START 2020209.0826
IEF032I STEP/FTPD/STOP  2020209.0826
CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC
VIRT:80K  SYS:   216K  EXT: 2220K  SYS: 9108K
ATB- REAL:12K  SLOTS: 0K
 VIRT- ALLOC:   7M SHRD:   0M
IEF375I  JOB/FTPSD   /START 2020209.0826
IEF033I  JOB/FTPSD   /STOP  2020209.0826
CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC

--
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: Started task stopping immediately. No error messages.

[David Spiegel]

Hi,
The start and stop happen because, another task is started, usually 
named FTPD1.

To see it, you can issue (on the console or via SDSF/EJES):
D A,FTPD1

As an aside, z/OS V2.5 will be the last release supporting IBM JES3.
After that, you will be unsupported, convert to Phoenix's JES3 or 
convert to JES2.


Regards,
David

On 2020-07-27 08:48, Skippy the Ancient wrote:

Responding to all posters, not just Mr Metz.

1. I already tried calling the proc from JCL.  It ran, stopped immediately and 
returned no error messages.
2. I started the proc with the MSGCLASS and did receive output.  It was 
identical to the JCL call; immediate stop and no error messages.  I will post 
this below.
3. The started task is a second FTP server supporting FTPS. To simplify, I 
copied the FTPD proc and renamed it FTPSD.  In theory, it is running exactly as 
the original FTPD task with a different port. (990)
4. The PROFILE update reads like this -
AUTOLOG
FTPSD JOBNAME FTPSD  ; FTPS SERVER
ENDAUTOLOG
PORT
989 TCP OMVS; FTPS SERVER
990 TCP FTPSD NOAUTOLOG ; FTPS SERVER

Here is the output of running the started task - (system specifics changed for 
security reasons)
  08:26:31  IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 
  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB  DSN=SYSX.TCPIP.SEZATCP
  08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY
  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB  DSN=SYSX.TCPIP.XXLOAD
  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSFTPD  DSN=SYSX.TCPIP.PARMLIB
  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
  08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSTCPD  DSN=SYSX.TCPIP.PARMLIB
  08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
  08:26:31  IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER 
FTPSD   , GROUP 
  08:26:31  ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD
  08:26:31  IEF403I FTPSD - STARTED - TIME=08.26.31
  08:26:31  IEF404I FTPSD - ENDED - TIME=08.26.31
//FTPSDJOB MSGCLASS=T, *
// MSGLEVEL=1
//STARTING EXEC FTPSD
 1 //FTPSDJOB MSGCLASS=T,   
  *
   // MSGLEVEL=1
 2 //STARTING EXEC FTPSD
 3 XXFTPSD  PROC MODULE='FTPD',PARMS='TRACE PORT 990'
 4 XXFTPD   EXEC PGM=&MODULE,REGION=0M,TIME=NOLIMIT,
   XX  PARM='POSIX(ON) ALL31(ON)/&PARMS'
   IEFC653I SUBSTITUTION JCL - 
PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'
 5 XXSTEPLIB  DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR
 6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR
 7 XXCEEDUMP  DD SYSOUT=*
 8 XXSYSOUT   DD SYSOUT=*
 9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL)
10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA)
  STMT NO. MESSAGE
 2 IEFC001I PROCEDURE FTPSD WAS EXPANDED USING SYSTEM LIBRARY 
SYSX.PROCLIB
IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD   , 
GROUP USSGRPX
IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
 Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002
IEF142I FTPSD FTPSD - STEP WAS EXECUTED - COND CODE 
IEF373I STEP/FTPD/START 2020209.0826
IEF032I STEP/FTPD/STOP  2020209.0826
 CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC
 VIRT:80K  SYS:   216K  EXT: 2220K  SYS: 9108K
 ATB- REAL:12K  SLOTS: 0K
  VIRT- ALLOC:   7M SHRD:   0M
IEF375I  JOB/FTPSD   /START 2020209.0826
IEF033I  JOB/FTPSD   /STOP  2020209.0826
 CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC

--
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: Started task stopping immediately. No error messages.

[Skippy the Ancient]

Responding to all posters, not just Mr Metz.

1. I already tried calling the proc from JCL.  It ran, stopped immediately and 
returned no error messages.
2. I started the proc with the MSGCLASS and did receive output.  It was 
identical to the JCL call; immediate stop and no error messages.  I will post 
this below.
3. The started task is a second FTP server supporting FTPS. To simplify, I 
copied the FTPD proc and renamed it FTPSD.  In theory, it is running exactly as 
the original FTPD task with a different port. (990)
4. The PROFILE update reads like this - 
AUTOLOG
   FTPSD JOBNAME FTPSD  ; FTPS SERVER  
ENDAUTOLOG 
PORT   
   989 TCP OMVS; FTPS SERVER   
   990 TCP FTPSD NOAUTOLOG ; FTPS SERVER   

Here is the output of running the started task - (system specifics changed for 
security reasons)
 08:26:31  IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB  DSN=SYSX.TCPIP.SEZATCP
 08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=STEPLIB  DSN=SYSX.TCPIP.XXLOAD
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSFTPD  DSN=SYSX.TCPIP.PARMLIB
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31 IAT4401  LOCATE FOR STEP=FTPD DD=SYSTCPD  DSN=SYSX.TCPIP.PARMLIB
 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY
 08:26:31  IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER 
FTPSD   , GROUP 
 08:26:31  ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD
 08:26:31  IEF403I FTPSD - STARTED - TIME=08.26.31
 08:26:31  IEF404I FTPSD - ENDED - TIME=08.26.31
//FTPSDJOB MSGCLASS=T, *
// MSGLEVEL=1
//STARTING EXEC FTPSD
1 //FTPSDJOB MSGCLASS=T,
 *
  // MSGLEVEL=1
2 //STARTING EXEC FTPSD
3 XXFTPSD  PROC MODULE='FTPD',PARMS='TRACE PORT 990'
4 XXFTPD   EXEC PGM=&MODULE,REGION=0M,TIME=NOLIMIT,
  XX  PARM='POSIX(ON) ALL31(ON)/&PARMS'
  IEFC653I SUBSTITUTION JCL - 
PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990'
5 XXSTEPLIB  DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR
6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR
7 XXCEEDUMP  DD SYSOUT=*
8 XXSYSOUT   DD SYSOUT=*
9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL)
   10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA)
 STMT NO. MESSAGE
2 IEFC001I PROCEDURE FTPSD WAS EXPANDED USING SYSTEM LIBRARY 
SYSX.PROCLIB
IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD   , 
GROUP USSGRPX
IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD
Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002
IEF142I FTPSD FTPSD - STEP WAS EXECUTED - COND CODE 
IEF373I STEP/FTPD/START 2020209.0826
IEF032I STEP/FTPD/STOP  2020209.0826
CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC
VIRT:80K  SYS:   216K  EXT: 2220K  SYS: 9108K
ATB- REAL:12K  SLOTS: 0K
 VIRT- ALLOC:   7M SHRD:   0M
IEF375I  JOB/FTPSD   /START 2020209.0826
IEF033I  JOB/FTPSD   /STOP  2020209.0826
CPU: 0 HR  00 MIN  00.08 SECSRB: 0 HR  00 MIN  00.00 SEC

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