Re: Batch Msgid Profile

[J O Skip Robinson]

We occasionally see this message:

IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED

I cannot find a current instance of this message in my system, but basically it 
means that the purported SAF userid is not defined to TSO--I guess either 
installed security product or UADS. The explanation of this message does not 
state how or where the 'default' comes from. The message is issued by IKJEFT01.

I imagine that a newly defined vanilla TSO userid would contain the defaults 
referred to by IKJ56644I. I don't know of any programmatic way to influence the 
default definition. If a valid userid does exist, the associated attributes are 
used. I especially don't know why anyone would actually choose *not* to see 
WTOs with msgid, but that's the default. This design may hark back to the 
advent of TSO, when it was the only interactive mechanism for the mainframe OS. 
In those days TSO was just as likely--maybe more so--to be used by clerical 
staff as by programmers. Messages and their ids would have been noise to many 
users. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Staller, Allan
Sent: Friday, November 21, 2014 9:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Batch Msgid Profile

IKJEFF10?


Is there a Default table or exit that is/can be set for all batch submits, so 
it would work without entering the 'PROF MSGID WTPMSG'?



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

Re: Batch Msgid Profile

[Staller, Allan]

IKJEFF10?


Is there a Default table or exit that is/can be set for all batch submits, so 
it would work without entering the 'PROF MSGID WTPMSG'?



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

Re: Batch Msgid Profile

[Ed Gould]

On Nov 19, 2014, at 11:18 AM, Paul Gilmartin wrote:


On Wed, 19 Nov 2014 09:58:57 -0700, Lizette Koehler wrote:


If you create a REXX or CLIST to do your batch work, then you can  
test the prof to see if MSGID and/or WTPMSG are on or off.  Then  
set them as you need them.


Any Application that run under TSO or ISPF can reset these  
entries.  And sometimes they do not set them back.  This is  
strictly a TSO function.  But some ISPF applications will tweak  
the TSO PROF function.



And if two batch IKJ jobs run concurrently, the final state is
indeterminate, even if they attempt to restore the settings.
There ought to be distinct commands to set such options for
the current session and to write them back to the RACF/UADS
data base.  Clearly the TSO designers were ignorant of the
requirements of multiprocessing.


Gil:

I do not know if processing has changed but in the day of UADS,
The UPT was updated and when the user logged off the system updated  
UADS.
I guess I would assume that with a RACF DB the same sequence of  
events are occurring but are going to the RACF DB instead.


Ed

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

Re: Batch Msgid Profile

[Shmuel Metz (Seymour J.)]

In <6847167582988560.wa.paulgboulderaim@listserv.ua.edu>, on
11/18/2014
   at 07:09 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>There's something wrong with this design: an underlying 
>assumption that no user will have two concurrent instances of 
>the TMP, and probably that the TMP will only be used for 
>interactive TSO sessions.

No, there is no such assumption.

Now, you may dislike the concept of a user profile, but that is a
separate issue.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Batch Msgid Profile

[Tony Harminc]

On 19 November 2014 12:18, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> And if two batch IKJ jobs run concurrently, the final state is
> indeterminate, even if they attempt to restore the settings.

Why do you claim that?

> There ought to be distinct commands to set such options for
> the current session and to write them back to the RACF/UADS
> data base.

Well, in a sense there are distinct commands - PROFILE and LOGOFF. The
PROFILE command updates the settings in an in-storage control block
(the User Profile Table, mapped by IKJUPT), and it's the logoff
processing in the TMP triggered by the LOGOFF command that writes the
UPT back to the security system (or UADS). The in-storage UPT is local
to each TSO session (address space), so the settings won't conflict.
If each session restores everything to the way it was before logoff,
there should be no problem.

Well of course this looks like a bad design, but it doesn't normally
have unpredictable results.

> Clearly the TSO designers were ignorant of the requirements of 
> multiprocessing.

Multiprogramming? No matter; the notion of running batch TSO jobs, and
for that matter of running multiple TSO sessions under the same userid
under any circumstances, long postdates TSO itself (there was no
batch-job TSO prior to MVS). It's hardly fair to fault the designers
of a Time Sharing Option that had at its core the notion of a single
user at an attached terminal for not anticipating these requirements,
certainly when there are so many other details to fault them for...

Tony H.

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

Re: Batch Msgid Profile

[Paul Gilmartin]

On Wed, 19 Nov 2014 11:41:33 -0600, John McKown wrote:
>
>​... And IBM has now basically said that
>TSO, but not ISPF or SDSF thankfully, is functionally ​stabilized. Which is
>one reason why I have embraced using a z/OS UNIX shell so much. I _really_
>wish that ISPF could be "ported" to run as a CUA (using curses?) and / or a
>X application on z/OS, likewise SDSF. What is particularly devastating to
>me is that until just a few years ago, SDSF came with source code. I
>remember looking at the terminal I/O code (native vs. ISPF). If I still had
>it, I could probably fake up a curses interface.
> 
Me, too.

How much of your SDSF wish could be satisfied by the Rexx (or other)
API to SDSF driving Curses or X?  As long as SDSF thinks in terms of
screen images, it will never deal with SIGWINCH satisfactorily.

And I wish for finer granularity of TSO functions.  I've often wished
I could do a TRANSMIT or RECEIVE without bringing up a TMP.
BPXWDYN is a boon, allowing (however belatedly) ready access to
DYNALLOC outside the TMP.  Similar independent access to IDCAMS
functions fronted by TSO would be valuable.

I do run ISPF noninteractively from Rexx "address TSO" largely to
use ISPF fine-grained PDS member serialization and to invoke
APF-authorized commands from ssh.  It would be better to have
an interface layer to BPX1EXM to support allocation of data sets.
What can you do with an authorized program with no data sets?

-- gil

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

Re: Batch Msgid Profile

[John McKown]

On Wed, Nov 19, 2014 at 11:18 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 19 Nov 2014 09:58:57 -0700, Lizette Koehler wrote:
> >
> >If you create a REXX or CLIST to do your batch work, then you can test
> the prof to see if MSGID and/or WTPMSG are on or off.  Then set them as you
> need them.
> >
> >Any Application that run under TSO or ISPF can reset these entries.  And
> sometimes they do not set them back.  This is strictly a TSO function.  But
> some ISPF applications will tweak the TSO PROF function.
> >
> And if two batch IKJ jobs run concurrently, the final state is
> indeterminate, even if they attempt to restore the settings.
> There ought to be distinct commands to set such options for
> the current session and to write them back to the RACF/UADS
> data base.  Clearly the TSO designers were ignorant of the
> requirements of multiprocessing.
>

​I don't think so. What the designers of TSO were was constrained by OS/360
memory, I/O, and CPU concerns. They also "wanted it now" and so problems
such as this were not addressed. I don't even know if IKJEFT01 was every
really meant to be run in a batch job. And IBM has now basically said that
TSO, but not ISPF or SDSF thankfully, is functionally ​stabilized. Which is
one reason why I have embraced using a z/OS UNIX shell so much. I _really_
wish that ISPF could be "ported" to run as a CUA (using curses?) and / or a
X application on z/OS, likewise SDSF. What is particularly devastating to
me is that until just a few years ago, SDSF came with source code. I
remember looking at the terminal I/O code (native vs. ISPF). If I still had
it, I could probably fake up a curses interface.



>
> -- gil
>
>

-- 
The temperature of the aqueous content of an unremittingly ogled
culinary vessel will not achieve 100 degrees on the Celsius scale.

Maranatha! <><
John McKown

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

Re: Batch Msgid Profile

[Paul Gilmartin]

On Wed, 19 Nov 2014 09:58:57 -0700, Lizette Koehler wrote:
>
>If you create a REXX or CLIST to do your batch work, then you can test the 
>prof to see if MSGID and/or WTPMSG are on or off.  Then set them as you need 
>them.
>
>Any Application that run under TSO or ISPF can reset these entries.  And 
>sometimes they do not set them back.  This is strictly a TSO function.  But 
>some ISPF applications will tweak the TSO PROF function.
> 
And if two batch IKJ jobs run concurrently, the final state is
indeterminate, even if they attempt to restore the settings.
There ought to be distinct commands to set such options for
the current session and to write them back to the RACF/UADS
data base.  Clearly the TSO designers were ignorant of the
requirements of multiprocessing.

-- gil

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

Re: Batch Msgid Profile

[Lizette Koehler]

There are a couple of other Lists that you might also like to join, if you have 
not done so, that might have some answers

TSO REXXhttp://www2.marist.edu/htbin/wlvindex?TSO-REXX
ISPFhttps://listserv.nd.edu/cgi-bin/wa?A0=ispf-l

I am not sure but I think this info maybe contained inside the SAF TSO Segment. 
 But that is just a guess.

If you create a REXX or CLIST to do your batch work, then you can test the prof 
to see if MSGID and/or WTPMSG are on or off.  Then set them as you need them.

Any Application that run under TSO or ISPF can reset these entries.  And 
sometimes they do not set them back.  This is strictly a TSO function.  But 
some ISPF applications will tweak the TSO PROF function.

I find it simpler to just add it to my SYSTSIN process.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Murawski,Joseph
> Sent: Wednesday, November 19, 2014 9:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Batch Msgid Profile
> 
> Is there a Default table or exit that is/can be set for all batch submits, so 
> it would
> work without entering the 'PROF MSGID WTPMSG'?
> 
> Thanks, Joe
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Tuesday, November 18, 2014 6:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Batch Msgid Profile
> 
> The PROFILE you are looking for is the TSO PROF command.  Anything you use
> for TSO can turn this on or off.  The easiest thing is to just make it part 
> of the job.
> 
> In the SYSTSIN DD *  section, add this
> 
> 
> //SYSTSIN  DD *
>   PROF MSGID WTPMSG
>   FCQUERY 
> 
> Hope this helps.
> 
> Lizette
> 
> 
> -Original Message-
> >From: "Murawski,Joseph" 
> >Sent: Nov 18, 2014 3:41 PM
> >To: IBM-MAIN@LISTSERV.UA.EDU
> >Subject: Batch Msgid Profile
> >
> >When I submit a job and do a 'fcquery devn()' or any command using
> >IKJEFT01 it does not show the msgid in the output(sysout).
> >But when I do the 'Profile MSGID' and then resubmit the job it will
> >show the msgid in the sysout.
> >I was wondering were is the default changed to update this for all batch 
> >submits?
> >
> >Thanks Joe
> >
> >

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

Re: Batch Msgid Profile

[Murawski,Joseph]

Is there a Default table or exit that is/can be set for all batch submits, so
it would work without entering the 'PROF MSGID WTPMSG'?

Thanks, Joe

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, November 18, 2014 6:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Batch Msgid Profile

The PROFILE you are looking for is the TSO PROF command.  Anything you use for 
TSO can turn this on or off.  The easiest thing is to just make it part of the 
job.

In the SYSTSIN DD *  section, add this


//SYSTSIN  DD *
  PROF MSGID WTPMSG
  FCQUERY 

Hope this helps.

Lizette


-Original Message-
>From: "Murawski,Joseph" 
>Sent: Nov 18, 2014 3:41 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Batch Msgid Profile
>
>When I submit a job and do a 'fcquery devn()' or any command using
>IKJEFT01 it does not show the msgid in the output(sysout).
>But when I do the 'Profile MSGID' and then resubmit the job it will
>show the msgid in the sysout.
>I was wondering were is the default changed to update this for all batch 
>submits?
>
>Thanks Joe
>
>

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

This communication, including attachments, is confidential, may be subject to 
legal privileges, and is intended for the sole use of the addressee. Any use, 
duplication, disclosure or dissemination of this communication, other than by 
the addressee, is prohibited. If you have received this communication in error, 
please notify the sender immediately and delete or destroy this communication 
and all copies.

TRVDiscDefault::1201

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

Re: Batch Msgid Profile

[Paul Gilmartin]

On Tue, 18 Nov 2014 16:50:56 -0700, Lizette Koehler wrote:

>The PROFILE you are looking for is the TSO PROF command.  Anything you use for 
>TSO can turn this on or off.  The easiest thing is to just make it part of the 
>job.
>
>In the SYSTSIN DD *  section, add this
>
>
>//SYSTSIN  DD *
>  PROF MSGID WTPMSG
>  FCQUERY 
>
>Hope this helps.
> 
And then it stays that way until the next job?  And if two jobs run
concurrently, they get to fight with each other?

When does it get written back to RACF/UADS?  Immediately when the
command is issued?  At job (step) termination?  Other (specify)?  When
is it sensed by other jobs?  At LOGON or step initiation?  Immediately?
Other (specify)?

There's something wrong with this design: an underlying assumption
that no user will have two concurrent instances of the TMP, and probably
that the TMP will only be used for interactive TSO sessions.

It's TSO.

-- gil

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

Re: Batch Msgid Profile

[Lizette Koehler]

The PROFILE you are looking for is the TSO PROF command.  Anything you use for 
TSO can turn this on or off.  The easiest thing is to just make it part of the 
job.

In the SYSTSIN DD *  section, add this 


//SYSTSIN  DD *
  PROF MSGID WTPMSG
  FCQUERY 

Hope this helps.

Lizette


-Original Message-
>From: "Murawski,Joseph" 
>Sent: Nov 18, 2014 3:41 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Batch Msgid Profile
>
>When I submit a job and do a 'fcquery devn()' or any command using IKJEFT01
>it does not show the msgid in the output(sysout).
>But when I do the 'Profile MSGID' and then resubmit the job it will show the 
>msgid
>in the sysout.
>I was wondering were is the default changed to update this for all batch 
>submits?
>
>Thanks Joe
>
>

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