Re: Is there a TSO SEND history anywhere?
FWIW No idea whether this would help finding where TSOSEND data is
logged (try a GTF + parms, if 'critically important') - but I would
suspect that the data is stored in system genned temp datasets, possibly
in VIOs, and deleted after the data I/O sent-and-displayed on
terminal screens. Perhaps displayed in the syslog. If it were
straight-forward, I would expect the IBM system savants to have posted a
resolution by now. If. HTH. Cheers etc.
Job TSOSEND:
//*
//* NOTE: NO LINE NUMBERS IN COLS 73-80 ALLOWED, ELSE CLIST FAILS! *
//* ¯ *
//*
//* NOTE: 'U' => TSO USERID(S); SPECIFY LIST OF USERIDS UNDER DESTIDS *
//* ¯ 'C' -> CONSOLE; SPECIFY MASTER ETC. UNDER CONSIDS *
//* *
//* 04/01/95 CMP *
//*
//*
//CLIST EXEC PGM=IKJEFT01,
// REGION=512K,
//* PARM='%TSOSEND DESTIDS SYSIN USERID'
// PARM='%TSOSEND CONSIDS SYSIN CONSOLE'
//*
//SYSPROC DD DISP=SHR,DSN=.ISPCLIB
//SYSTSIN DD DUMMY
//SYSTSPRT DD SYSOUT=*
//CONSIDS DD *
//*
//DESTIDS DD *
...
//SYSIN DD *
Dear MVS OPS,
...
Thanks a lot.
Chris
/*
//*
//
CLIST TSOSEND:
--
PROC 2 DESTLIST MESSAGE DEBUG USERID CONSOLE
/*---*/
/* N.B. DEFAULT IS 'NOW' */
/* 'LOGON' -> 'NOW' IF LOGGED ON, ELSE AT LOGON TIME. */
/* 'SAVE' -> ONLY AT NEXT LOGON TIME (OR LISTBC) */
/* */
/* PARMS: DESTLIST DDNAME OF USERS/CONSOLES TO WHOM MESSAGE IS TO */
/* BE SENT - DEFAULT=NONE */
/* MESSAGE: DDNAME OF MESSAGE TEXT TO BE SENT - DEFAULT=NONE */
/* DEBUG: SETS TRACE ON - DEFAULT=OFF */
/* */
/* 02/05/00 CMP - SET EXIT CODE TO 0 */
/* 13/12/94 CMP - ALLOW SENDING TO USERID(S) OR TO MVS CONSOLE(S) */
/* 17/04/89 CMP */
/*---*/
CONTROL: +
CONTROL END(ENDO)
IF &DEBUG = DEBUG | &DEBUG = D THEN +
CONTROL LIST SYMLIST CONLIST MSG ASIS
ELSE +
CONTROL NOLIST NOSYMLIST NOCONLIST NOMSG ASIS
ERROR: +
ERROR DO
SET CC = &LASTCC
IF &CC = 400 THEN RETURN
ELSE DO
WRITE ERROR WITH CONDITION CODE = &CC OCCURRED : INTERRUPT AT LABEL +
'ERROR'
WRITE CLIST RUN ABANDONNED
GOTO EXIT
ENDO
ENDO
IF &USERID ¬= THEN SET TO = USER
ELSE IF &CONSOLE ¬= THEN SET TO = CN
ELSE +
WHERE: +
DO
WRITE YOU MUST SPECIFY PARAMETER 'USERID' OR 'CONSOLE'
WRITE
GOTO EXIT
ENDO WHERE
SET SENDTO =
SET K = &&K
SET USREC = &&&DESTLIST
SET MSGREC = &&&MESSAGE
SET MAXCC = 0
OPENFILE &DESTLIST INPUT
GETFILE &DESTLIST
DO I = 0 TO 99 WHILE &MAXCC = 0
SET USER = &USREC
SET J = &SYSINDEX(&STR( ),&USER,1)
SET J = &J - 1
SET USER = &SUBSTR(1:&J,&USER)
SET SENDTO = &STR(&SENDTO&USER,)
GETFILE &DESTLIST
ENDO
CLOSFILE &DESTLIST
IF &I > 0 THEN +
DO
SET LSENDTO = &LENGTH(&STR(&SENDTO)) - 1
SET SENDTO = &SUBSTR(1:&LSENDTO,&STR(&SENDTO))
SET MSG = &&MSG
SET MAXCC = 0
OPENFILE &MESSAGE INPUT
GETFILE &MESSAGE
DO J = 1 TO 99 WHILE &MAXCC = 0
SET MSG&J = &SUBSTR(1:71,&MSGREC)
SET K0 = 1
DO I = 1 TO 99 WHILE &K&EVAL(&I-1) > 0
SET K&I = &SYSINDEX(&STR('),&STR(&MSG&J),&K&EVAL(&I-1))
IF &K&I > 0 THEN SET K&I = &K&I + 1
ENDO
DO L = &I-2 TO 1 BY -1 WHILE &K&L > 0
SET MSG&J = &SUBSTR(1:&K&L-1,&STR(&MSG&J))&STR(')+
&SUBSTR(&K&L:&LENGTH(&STR(&MSG&J)),&STR(&MSG&J))
ENDO
GETFILE &MESSAGE
ENDO
SET J = &J - 1
DO I = 1 TO &J
SEND '&MSG&I' +
&TO(&STR(&SENDTO)) LOGON
ENDO
ENDO
EXIT: +
EXIT CODE(0)
On 04/02/2022 18:43, Charles Mills wrote:
> 1. I am running ISPF full screen. So once I hit Enter the message seems to
> be gone, gone, gone.
>
> 2. The particular SENDs that I am interested in is sent from a batch job
> with Rexx Address TSO "SEND ... but the question was intended to be general.
> I don't see it in SYSLOG. I do see the SENDS that JES2 uses for NOTIFY=
>
> 3. Seems to me I tried Session Manager years ago and did not like it.
>
Re: Does this make no sense or is it just me?
Tony, thanks for the thorough response. I wanted a reality check. I will submit an RCF. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Friday, February 4, 2022 4:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Does this make no sense or is it just me? On Fri, 4 Feb 2022 at 18:07, Charles Mills wrote: > > Does the following make sense to anyone? From the JCL Reference, at least > several recent versions including V2R5, Chapter 6. Job control statements on > the output listing. It seems boggled to me on several levels. I don't think > it is true, and I think the references to specific programs are superfluous > (or alternatively, incomplete). Am I off base? > > EXEC overriding parameters: A procedure EXEC statement appears in the job > log listing exactly as it > appears in the procedure. Overridden parameters must be shown by the program > being executed: > > . For the EXEC statement that executes the assembler program, the Diagnostic > Cross Reference and > Assembler Summary produced by the assembler program shows the overriding > parameters. > > . For the EXEC statement that executes the linkage editor, the linkage > editor listing shows the overriding > parameters. I think this is probably a classic result of the interaction among product developers, tech writers, and support/change team people. Certainly it's not correct, but more than that, I think it just reflects this uneasy mix of people with the same high level goal but different understanding. I speculate: Someone probably complained to IBM that the EXEC statement in the JCL listing doesn't directly show the result of the various substitutions that are possible. (Of course there are the SUBSTITUTION JCL messages, but they're virtulaly unreadable.) Someone in JCL (what I think of as the IEF team) said "well of course we don't show that - it's up to the program being invoked to show its own arguments after everything is resolved. For example, the assembler shows that stuff right at the top." The tech writers didn't really understand that, but went to the ASM people and asked how to explain the example of showing the overriding parameters. Someone there told them it's under the rubric "Diagnostic Cross Reference and Assembler Summary" So they put that in the book as an example, and then someone else complained that there is no example for the linkage editor. So they put that in. Then someone complained about something else, and they thought, OK, enough, and stopped putting in examples. What's obviously missing is someone with the big picture who would understand that the level of explanation and examples is all wrong, and that a more general explanation of how *any* program you invoke *may* provide a listing of its arguments, but that what the JCL resolves to is found in those SUBSTITUTION JCL messages. Just maybe a reminder about MSGLEVEL would be appropriate. I see this all the time for much smaller products that I work on; the tech writers are forever trying to clean up and organize while responding to complaints and requests for clarification from customers and Support. They think of themselves as the core of the document production process, who refer to SMEs (Subject Matter Experts) for the technical nitty-gritty. But no amount of technical detail is enough by itself when the overall view is missing. Who should provide that? It depends on the sizee and nature of the organization. Ideally one needs a single senior developer who is very competent in written English as well as both the immediate subject matter and the larger environment both technical and documentary. And who isn't spending 120% of his/her time on writing code. So it goes. 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: What is the audit basis to prevent read access to z/OS PARMLIB's?
The IBM guidelines for protecting PARMLIB in the RACF Security Administrator's Guide indicate that default access of READ is acceptable; however, they qualify this as follows: "UACC should be NONE if any members contain passwords, or other sensitive information, such as the ACBPW password in the TSOKEYxx member." How often does someone review PARMLIB looking for passwords and the like? Most likely never. If you lock it down, there are no worries you've missed something. Whereas most of the configuration information in PARMLIB is in storage for anyone to view (e.g., current list of APF libraries), there are a few things in fetch-protected storage that require authorization to see, one being the PPT. READ access to PARMLIB would let me see what additions and modifications an installation has made to the PPT, in particular whether Bypass Password Protection or a System Key have been assigned to any program that could be exploited. This is a reason for also protecting RACF's DSMON program ICHDSM00 as it provides PPT information. I tend to agree with those advocating for least necessary privilege. If access isn't explicitly needed, don't provide it, or at least monitor activity to discover who is checking you out. Why make it easy for someone to probe your system undetected. The STIG and the RACF SAG should both be amended to indicate the PARMLIB concatenation, not just SYS1.PARMLIB. Regards, Bob Robert S. Hansel35 years of RACF Experience Lead RACF Specialist 2021 #IBMChampion RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.twitter.com/RSH_RACF www.rshconsulting.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
