We are trying to use VSAM RLS to share SCLM's databases across many
partition but we receive some unespected errors: does anyone know why?
If we use sclm panels, while scanning project definition we receive an "I/O
error reading accnt file" and if we try to access the same dataset in batch
we get the following message:
IEC161I 006-027,CO074REP,REPRO,,,XLX000,SCLMTI.PROJDEFS.ACCTDB,
IEC161I SCLMTI.PROJDEFS.ACCTDB.DATA,CATALOG.ICF1.VXL0000.
We followed instructions coming from IBM's manuals in order to activate
VSAMSMS and it's related structures and to define the varios databases
needed by sclm.
Best regards and thanks in advice.
Cedacri Ovest
Luca Aluffi
We don't use this, so all my knowledge is from reading and a recent CICS/TS
1.3 class (last week) that discussed this topic for almost 2 days.
Supposedly, the implementation of "Transactional VSAM" (that allows multiple
batch updaters) was supposed to be in V2R10, but did not materialize (our
instructor also said this was not in any announced version of z/OS). My
interpretation of this would be that TSO and/or the TSO TMP would be limited
to the original VSAM Share Option limitations.
I don't know how IMS would use this, but CICS uses built-in facilities to
manage this. CICS/TS added a whole new File Control Domain for VSAM-RLS
(separate from the original File Control Domain). The way I understand it,
this works hand-in-hand with the CICS/VR product to perform all the
journaling of before and after images to the MVS Logger and manages any
subsequent batch recoveries. The CICS regions "attach" to the SMSVSAM
address space and thread all VSAM-RLS access through this interface.
For those familiar with DB2 and IMS, there is now a shared buffer management
configuration for VSAM-RLS, management of indoubt units of work and IRLM-like
locking issues involved in setting up the SMSVSAM environment. Personally, I
don't understand why this was done. IMS and DB2 have very mature
Sysplex-aware sharing environments that have worked well for years. This
incremental piece meal approach being used for VSAM feels like a "deal with
the devil" for some very large IBM customer. Share Options (3,3) approaches
with a "coordinator task" have been around for years for the unique
requirements of a few VSAM dependent products.
Hope This Helps,
Robert Zenuk
robz...@aol.com
The Mesaage IEC161I 006-027 states
ccc = 26, or 27, or 28 - An attempt was made to open a VSAM data set which
has been DEFINED with RLS attributes or for RLS processing on a level of
DFSMS that does not support RLS (Lower than HDZ11C0).
ccc = 27 - HDZ11E0 and above - Attempt to open a VSAM data set for non-RLS
input processing with SHAREOPTIONS other than 2,x and the data set is
already opened for RLS processing.
I assume you have DFSMS with the correct level, so I would check that you
re-generated all the project definitions (including alternates) to have the
VSAMRLS=YES parameter. If this still happens let me know what you were
doing in SCLM when you got the IEC161I message.
Regards,
John Philp
SCLM Development & Support
APC, IBM Global Services, Perth Australia
"Aluffi, Luca"
<L.Aluffi@CEDACRI To: ISP...@listserv.nd.edu
OVEST.IT> cc:
Sent by: ISPF Subject: SCLM and VSAM RLS
discussion list
<ISPF-L@listserv.
nd.edu>
26/03/2002 07:12
PM
Please respond to
ISPF discussion
list