Moving from XCF-local to single-system sysplex environment
Daniel Allen
Can we create a COUPLExx parmlib member with LOGR only ?
Or do we need all five COUPLE facilities ?
Skip Robinson
exists. Single systems must now run as Monoplex. That being said, there is
no problem running a system in Monoplex mode, which allows system logger
to write to DASD-only data sets.
Although it may not suit your needs, you can also run multiple systems in
Basic Sysplex mode, which allows limited sharing of resources like console
without any CF access.
.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
JO.Skip....@sce.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
R.S.
> We have a XCF-local system with no access to a coupling facility. However, we would like to run CICS/TS 4.1 with DASD-only logging.
>
> Can we create a COUPLExx parmlib member with LOGR only ?
>
> Or do we need all five COUPLE facilities ?
No, and no.
You have to create two CDS types: sysplex (aka XCF) and LOGR.
Oh, BTW, there are 7 CDS types.
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
S d Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru S dowego,
nr rejestru przedsi biorców KRS 0000025237
NIP: 526-021-50-88
Wed ug stanu na dzie 16.07.2010 r. kapita zak adowy BRE Banku SA (w ca o ci wp acony) wynosi 168.248.328 z otych.
Daniel Allen
Mark Zelden
>We have a XCF-local system with no access to a coupling facility. However,
we >would like to run CICS/TS 4.1 with DASD-only logging.
>
>Can we create a COUPLExx parmlib member with LOGR only ?
>
>Or do we need all five COUPLE facilities ?
Don't you have a monoplex now and WLM couple data sets? Or are
you running with the "default" WLM policy? The only XCFLOCAL
system I've worked on in years is my onepack system.
But to answer your question: You don't need a CF. You can run a
monoplex with sysplex (XCF) couple data sets, define your
LOGR couple data sets, and use DASD only logstreams.
I support many monoplex LPARs that run in that mode (but they
also have WLM couple data sets).
If you look at the doc section of my web site for "Doc for setting up
WLM in a MONOPLEX", the first few steps are the same but then you
need the logger couple data sets. See MVS Setting Up a Sysplex
for details.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
Rabbe, Luke
ARM
BPXMCDS
CFRM
LOGR
SFM
WLM
What's the 7th type?
Luke
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of R.S.
Sent: Friday, February 25, 2011 12:03 PM
To: IBM-...@bama.ua.edu
Subject: Re: Moving from XCF-local to single-system sysplex environment
Ayon, John
Luke
No, and no.
________________________________
NOTE: This electronic message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error, any unauthorized review, use, disclosure, distribution or copying of this message is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature or writing.
Staller, Allan
<snip>
I know these CDS types:
ARM
BPXMCDS
CFRM
LOGR
SFM
WLM
What's the 7th type?
</snip>
R.S.
aka XCF CDS is missing.
Just to complement: XCF is mandatory, while BPX aka OMVS aka (no! USS
agan?) is not, it depends on configuration and needs.
The other optional CDSses are SFM and ARM. CFRM is mandatory when you
want to use CF. LOGR is mandatory in almost all scenarions because it is
mandatory for System Logger. WLM was already discussed - theoretically
you can live without it, but the system is crippled.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2011-02-25 20:54, Staller, Allan pisze:
> OMVS
>
> <snip>
> I know these CDS types:
>
> ARM
> BPXMCDS
> CFRM
> LOGR
> SFM
> WLM
>
> What's the 7th type?
> </snip>
>
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
S d Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru S dowego,
nr rejestru przedsi biorców KRS 0000025237
NIP: 526-021-50-88
Wed ug stanu na dzie 16.07.2010 r. kapita zak adowy BRE Banku SA (w ca o ci wp acony) wynosi 168.248.328 z otych.
----------------------------------------------------------------------
Stan Weyman
Stan Weyman
Senior Software Engineer
stan....@emc.com
EMC˛ (508)249-3966
where information lives
It is wise to keep in mind that neither
success nor failure is ever final...
Stan Weyman
Stan Weyman
Senior Software Engineer
stan....@emc.com
EMC² (508)249-3966
where information lives
It is wise to keep in mind that neither
success nor failure is ever final...
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Staller, Allan
Sent: Friday, February 25, 2011 2:55 PM
To: IBM-...@bama.ua.edu
Subject: Re: Moving from XCF-local to single-system sysplex environment
Mark Zelden
>WLM was already discussed - theoretically
>you can live without it, but the system is crippled.
>
Not really. Especially if you you have enough capacity.
The OP looked like a vendor, and just as my onepack system runs great
with the default WLM policy (no WLM policy), I could see z/OS running fine in
a small development environment that way also.
STCs fall into a SYSTEM or SYSSTC service class based on their
attributes (and probably the place they would be if you did have a decent WLM
policy), TSO users fall into a TSO service class, and batch falls into
SYSOTHER (discretionary).
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
----------------------------------------------------------------------
Staller, Allan
Al Staller | Z Systems Programmer | KBM Group | (Tel) 972 664 3565 | allan....@kbmg.com
Chokalingam Thangavelu
Please let me know if there is any document that describes SYS1 datasets
and its associated product names.
For example SYS1.SIGY* datasets are related to Enterprise Cobol.
Regards,
Chokalingam Thangavelu
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Mark Zelden
<thangavelu....@WIPRO.COM> wrote:
>Hi,
>
>Please let me know if there is any document that describes SYS1 datasets
>and its associated product names.
>
>For example SYS1.SIGY* datasets are related to Enterprise Cobol.
>
There isn't any one document. You need the program directory for each
product. But since most of the products come with a ServerPac, you
can use the "CPAC.PGMDIR" softcopy version.
You won't find the entire data set name, just the LLQ (low level qualifier),
which matches the DDDEF name in SMP/E that is required.
Another place you can find the information is the "Serverpac Installing
Your Order" document.
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
----------------------------------------------------------------------
Ernie Takeuchi
Ernie.
"Chokalingam Thangavelu" <thangavelu....@WIPRO.COM> wrote in message news: <A4CEC1E86E5BA1488D84...@BLR-EC-MBX02.wipro.com>...
> Hi,
>
> Please let me know if there is any document that describes SYS1 datasets
> and its associated product names.
>
> For example SYS1.SIGY* datasets are related to Enterprise Cobol.
>
> Regards,
> Chokalingam Thangavelu
R.S.
> IBM only requires that you keep the last level qualifier intact.
renamed. See SERVERPAC Installation Dialog and display dataset name by
category "rename allowed".
Answer to original question: No, there is no single document describing
dsames and products. Yes, you can get the information, but it reuires
some investigation. Quick and dirty method: look at member names, the
membername prefix is the clue.
Other sources of information: SMP/E (DDDEFS, Products, FMIDs), ServerPac
Dialog, ServerPas Installation Guide, Program Directories.
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
S d Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru S dowego,
nr rejestru przedsi biorców KRS 0000025237
NIP: 526-021-50-88
Wed ug stanu na dzie 16.07.2010 r. kapita zak adowy BRE Banku SA (w ca o ci wp acony) wynosi 168.248.328 z otych.
----------------------------------------------------------------------
Rob Scott
For example, SGIMxxxx in the LLQ (or DDDEF) will mean SMP/E as GIM is its product prefix
I am unsure if this list is generally available, however most ISVs will either have a pre-registered range of prefixes that they manage internally or will request a new one for a new product.
Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com
Chris Mason
I'm going to try guessing what your *real* question might be for which there
is a very simple answer.
This is a bit like the Irishman who when asked the way, answered that if he
wanted to go there he wouldn't be starting from here, so he wouldn't! It's as if
he had suggested from where you really should be starting, so you should!
Let us say you had stated that you were relatively new to z/OS - and possibly
other IBM operating systems, that you had noticed that there tended to be
three characters, usually letters, that were always associated with a
particular product and that these three characters were used in the data set
names which were associated with a product, especially the data sets, often
partitioned data sets, "libraries", which were created using SMP, these days
SMP/E.
Your question now could be to ask where you might find a table where the left
column was the three characters and the next column was the common name
for the product.
Using your example, you would be looking for a row in the table with "IGY" in
the left column and "Enterprise COBOL" in the next column.
Step forward the z/OS MVS System Messages Volume 1 (ABA - AOM), SA22-
7631-21, "Message directory section":
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2M1B0/1.3
Actually the row corresponding you your example is the following:
<quote>
IGY - VS COBOL II
</quote>
In fact there is a third column which is the identification of the manual
containing the messages corresponding to the three characters.
-
Note that "SYS1" just happens to be the prefix selected in the 1960s as a way
to distinguish IBM-inspired data sets from data sets which are not IBM-
inspired - or I'll accept any other means to define what a SYS1 prefix is all
about if it holds water.
Note also that the "S" in your example, SYS1.SIGY*, is a convention related
to SMP.
In order to try to be more precise about the "S", I waded into water that
caused me to get rather out of my depth. That'll teach me to try to provide
comprehensive answers when I know only half or so of the story!
Perhaps someone still reading can guide all of us who might be interested in
unravelling "Software Delivery Standard Packaging Rules for z/OS-Based
Products", SC23-3695-10, on the SMP/E bookshelf where, in the
chapter "Naming Conventions", section "Library Names", I found both a
reference to the three characters[1] and a reference to that initial
character, "S" in your example as "the letter for a distribution library or a
target library".
Chris Mason
[1]
<quote>
Component Identifier (COMP ID)
In the SMP/E environment, code for one product must be uniquely
distinguishable from code for other products. The best way to keep your code
unique is to start the names of all the elements and load modules for that
product with a single unique 3-character identifier. This identifier is called a
component code. IBM is offering to register the component codes for your
products. The registration ensures that your component code is not used by
another products that are registered.
Send a note to ELE...@us.ibm.com or ask your IBM representative to
contact IBM Poughkeepsie, Department FPLA.
</quote>
On Tue, 1 Mar 2011 18:13:29 +0530, Chokalingam Thangavelu
<thangavelu....@WIPRO.COM> wrote:
>Hi,
>
>Please let me know if there is any document that describes SYS1 datasets
>and its associated product names.
>
>For example SYS1.SIGY* datasets are related to Enterprise Cobol.
>
>Regards,
>Chokalingam Thangavelu
Chris Mason
As a point of accuracy, IBM allows you to use any data set name you like[1].
I'm aware of this having been *very* inventive in organising a set of systems
for "hands-on" education use. This set of systems were copied from an early
stage in the building of a production system and - here's the key point - never
needed SMP support.
So I think the point you are really making here is that, if you want an easy life
running SMP, try to keep fairly close to the names IBM has created for you.
But I'll very willingly have this point disputed/clarified/refined.
Chris Mason
[1] With some, in principle, rare exceptions such as some of the data sets
used by the IP component of Communications Server - which first saw the
light of day as "TCP/IP for VM" - and hasn't quite got around to shaking off
completely the VM legacy of allocation by data set name so allowing complete
flexibility in the naming of its plethora of run-time data sets.
On Tue, 1 Mar 2011 05:55:31 -0800, Ernie Takeuchi
<e.m.ta...@ATT.NET> wrote:
>IBM only requires that you keep the last level qualifier intact. You can find
all your IBM datasets if you have a file on disk called **.INSTGUID.BOOK. This
file should have been made available when your system was first installed.
You can read the book by invoking the exec EOXVSTRT for book manager.
Look at Appendix A and you should have all your products that you had
installed with all their last level qualifiers.
>
>Ernie.
>
>
>
>"Chokalingam Thangavelu" <thangavelu....@WIPRO.COM> wrote in
message news: <A4CEC1E86E5BA1488D84F46C46CD959009B2592E@BLR-EC-
MBX02.wipro.com>...
Staller, Allan
In order to try to be more precise about the "S", I waded into water
that
caused me to get rather out of my depth. That'll teach me to try to
provide
comprehensive answers when I know only half or so of the story!
</snip>
In SMP/E parlance, HLQ.Sxxxxxxx is generally a SMP/E target.
HLQ.Axxxxxxx is generally a SMP/E DLIB (Distribution Library).
SMP/E itself imposes no such restrictions. This is a convention
established by the IBMers in charge of packaging the products.
HTH,
Shmuel Metz , Seymour J.
at 03:04 PM, Ed Gould <ps2...@YAHOO.COM> said:
>One curious holdover is the ISPF/PDF libraries. If memory serves me
>originally the name had to be SYS1. with various releases of MVS the
>ability to concatenate the libraries the sys1.lpalib has made it
>moot.
Perhaps you're thinking of the old requirement that it be cataloged in
the Master Catalog.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)