| Author |
Message |
chkiran2
New User
Joined: 24 Jun 2004
Posts: 25
Location: Gurgoan
|
|
|
|
Hi
I am new to REXX. I have seen some examples using REXX which contains SYSLBC Parameter. Can any one please explain me what it actually does? Here the way it has been used?
//SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR |
|
| Back to top |
|
 |
References
|
 Posted: Tue Jun 29, 2004 9:57 am Post subject: Re: SYSLBC Parameter |
|
|
|
|
bluebird
Specialist
Joined: 03 Feb 2004
Posts: 144
|
|
|
|
hello,
can u sahow the code ?
the example shown looks more like JCL to me... |
|
| Back to top |
|
|
bluebird
Specialist
Joined: 03 Feb 2004
Posts: 144
|
|
|
|
After further investigations,
SYS1.brodcast is a message dataset that keeps all tso message that were sent. if you were not connected to TSO the messages sent to u are stored there. Our shop allocates a brodcast dataset to each userid, so a user's messages are in its own brodcast dataset.
to see messages you may have missed type TSO LISTBC.
to figure out where are stored your msgs see ur user logon proc find //SYSLBC DDname the dsn is your messages repository file.
So SYSLBC is TSO message dataset DDNAME
hope it helps |
|
| Back to top |
|
|
bluebird
Specialist
Joined: 03 Feb 2004
Posts: 144
|
|
|
|
to complement what I said in previous post :
this is from dave elder vass' book : MVS systems programming
| Code: |
7.7.7 SYS1.UADS and SYS1.BRODCAST
In theory these two datasets are optional, but in practice you will always find them necessary, as they are both required by TSO. SYS1.UADS holds details of all TSO userids authorised to use the system, and details of their logon procedures, account numbers, etc. If you have RACF Version 1.8 or higher you can use RACF to perform these functions instead of SYS1.UADS, but I would recommend that even if you use this for day-to-day operation you keep a copy of UADS with at least your systems programmers' ids in it which you can use in an emergency if RACF is unusable.
SYS1.BRODCAST holds broadcast messages (e.g. NOTIFY messages) for TSO users which can't be delivered at the time of their creation.
If you are using them, both of these datasets are usually allocated in your MSTJCLxx member, so it is crucial to the initialisation of the master scheduler that they exist and are correctly cataloged in the master catalog. They are placed by CBIPO on the SYSRES pack, but I recommend moving them onto another system pack, for the same reasons as for PARMLIB. These datasets are discussed in a little more detail in chapter 10 below on TSO implementation.
|
see : http://www.mvsbook.fsnet.co.uk |
|
| Back to top |
|
|
|
|
