View previous topic :: View next topic
|
Author |
Message |
Ron Barnes
New User
Joined: 09 Mar 2021 Posts: 5 Location: USA
|
|
|
|
Hello All,
This is my first post so please bear with me as I become accustomed to this forum.
I am NOT a z/OS Admin. I am a COBOL Programmer that knows his way around a mainframe.
That being said.
I have been assigned to a new group in my organization. I am there to just support my groups access to the mainframe. IE... Assign user names, reset passwords, connect DB2 Databases to users. Pretty much the mundane stuff that a real admin does not have the time to do.
I was asked to alter the Logon Scrips for all users in order to update the IMS320 Datasets to use IMS322. I can work my way around REXX and JCL. The issue I'm having is I cannot find where the Logon scrips would be kept nor what they would be called. When I made a passing query to a co-worker, the response was 'it's in with the JCL'.
I found a few *.*.JCL PDS's in the mainframe and looking through them, I do not seem to be able to locate what I'm trying to change.
Would anyone here have any insights (Generically of course) as to what a logon script would be called and where it may be found?
Regards,
-Ron |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
The default LOGON proc has //SYSEXEC an/or //SYSPROC DD statements. Start there.
The usual LOGON script is started by
// EXEC PGM=IKJEFT01,PARM='TSO command to start the LOGON script'
in the LOGON proc. |
|
Back to top |
|
|
Ron Barnes
New User
Joined: 09 Mar 2021 Posts: 5 Location: USA
|
|
|
|
steve-myers wrote: |
The default LOGON proc has //SYSEXEC an/or //SYSPROC DD statements. Start there.
The usual LOGON script is started by
// EXEC PGM=IKJEFT01,PARM='TSO command to start the LOGON script'
in the LOGON proc. |
Thank you! |
|
Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006 Posts: 792 Location: Pennsylvania
|
|
|
|
To see your logon proc and input parms,and find script.
In SDSF:
DA OTSU - See all active users
Select your user ID to see your logon proc
Find your logon script as shown by Steve above - PARM=
Another way to find this script:
TSO ISRDDN - From any command line shows datasets allocated to your tso session
Then:
MEM Scriptname - Will find the script within your allocation
Under ACT use V to view this script |
|
Back to top |
|
|
Ron Barnes
New User
Joined: 09 Mar 2021 Posts: 5 Location: USA
|
|
|
|
daveporcelan wrote: |
To see your logon proc and input parms,and find script.
In SDSF:
DA OTSU - See all active users
Select your user ID to see your logon proc
Find your logon script as shown by Steve above - PARM=
Another way to find this script:
TSO ISRDDN - From any command line shows datasets allocated to your tso session
Then:
MEM Scriptname - Will find the script within your allocation
Under ACT use V to view this script |
This got me exactly where I wanted to be!!
Thank you Sir!
Thank you Both! |
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2588 Location: Silicon Valley
|
|
|
|
Additional info:
Look in SYS1.PROCLIB(JES2) for the PROC00 DD name. That will show you the names of the PDSes that have the logon procs. |
|
Back to top |
|
|
Joerg.Findeisen
Senior Member
Joined: 15 Aug 2015 Posts: 1308 Location: Bamberg, Germany
|
|
|
|
Pedro wrote: |
Additional info:
Look in SYS1.PROCLIB(JES2) for the PROC00 DD name. That will show you the names of the PDSes that have the logon procs. |
Use $d proclib instead.
Code: |
$HASP319 PROCLIB(PROC00)
$HASP319 PROCLIB(PROC00) DD(1)=(DSNAME=<dsn>), .. |
|
|
Back to top |
|
|
Willy Jensen
Active Member
Joined: 01 Sep 2015 Posts: 725 Location: Denmark
|
|
|
|
also:
TSO LU your-userid TSO NORACF
to check if an initial command has been defined. |
|
Back to top |
|
|
Ron Barnes
New User
Joined: 09 Mar 2021 Posts: 5 Location: USA
|
|
|
|
This Place is Awesome!! |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
Just a thought that may make things easier in the future ...
One of the things that I used to do back in the day when I was responsible for the SAS installations and maintenance, was the use of aliases, which meant that we could upgrade software without changes to the user procs or jobs that they submitted.
basically
SASPROD was aliased to SAS93 .... the 9.3 version
SASTEST was aliased to SAS94
So when the testing was complete and everyone happy, all we had to do was to redefine the alias to point to the new version of the software
Of course sometimes we had to add or remove a DD statement, but using PROCs made the changes minimal, and once again in one centralised library. |
|
Back to top |
|
|
Ron Barnes
New User
Joined: 09 Mar 2021 Posts: 5 Location: USA
|
|
|
|
expat wrote: |
Just a thought that may make things easier in the future ...
One of the things that I used to do back in the day when I was responsible for the SAS installations and maintenance, was the use of aliases, which meant that we could upgrade software without changes to the user procs or jobs that they submitted.
basically
SASPROD was aliased to SAS93 .... the 9.3 version
SASTEST was aliased to SAS94
So when the testing was complete and everyone happy, all we had to do was to redefine the alias to point to the new version of the software
Of course sometimes we had to add or remove a DD statement, but using PROCs made the changes minimal, and once again in one centralised library. |
That is a very good idea. Kind of like using Symbolic in JCL?
Regards,
-Ron |
|
Back to top |
|
|
Willy Jensen
Active Member
Joined: 01 Sep 2015 Posts: 725 Location: Denmark
|
|
|
|
Re alias, I will suggest that you also look at SYMRELATE, i.e.
DEF ALIAS(NAME(SYSA.PROCLIB) -
SYMBOLICRELATE(SYSA.&ZOSVER..PROCLIB))
Slightly more complex as you need to define a system symbol, in this sample ZOSVER, but afterwards you only have to change the symbol to affect multiple datasets. System symbols can be changed dynamically. |
|
Back to top |
|
|
|