Hi,
Let me SHARE a little pain and maybe save you some.
We are currently in the process of upgrading from 1.4 to 1.6. On
the 1.6 system we hit the following problem.
ALTER -
FOO.GFOO0901.AIPMASTR/ -
READPW( )
IDC3014I CATALOG ERROR
IDC3009I ** VSAM CATALOG RETURN CODE IS 18 - REASON CODE IS IGG0CLE8-12
IDC0532I **ENTRY FOO.GFOO0901.AIPMASTR NOT ALTERED
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8
This works just fine on z/OS R4.
ALTER -
FOO.GFOO0901.AIPMASTR/ -
READPW( )
IDC0180I PASSWORD SPECIFICATION FOR FOO.GFOO0901.AIPMASTR MAY BE
IDC0180I INEFFECTIVE
IDC0531I ENTRY FOO.GFOO0901.AIPMASTR ALTERED
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
It turns out the new message is documented in the z/os V1.7 MVS System
Messages Vol 6.
12 Explanation: An attempt to alter a data set's security
information was rejected. Security information is no
longer supported in catalogs.
Programmer Response: Remove the security-related
parameters (READPW, UPDATEPW, MASTERPW, CONTROLPW,
ATTEMPTS, CODE, AUTHORIZATION) and retry the alter
request.
.
Apparently the loophole for allowing these to pass is closed at z/OS R5
for IDCAMS ALTER. Starting from that
release, those unsupported parms will lead to IDC3009I RC18 RSN12.
As far as the DEFINE goes, the same job that gets the IDC3009I
when it tries to ALTER the READPW, is able to successfully DELETE
and then DEFINE the same data set, with all of the PW() parameters
specified. The last few lines of the DEFINE CLUSTER command and
the resulting messages from the job are:
...
INDEX -
( NAME(FOO.GFOO0901.AIPMASTR.INDEX) -
ATTEMPTS(0) -
MASTERPW( ) -
CONTROLPW( ) -
UPDATEPW( ) -
READPW( ) -
CISZ(4096) )
IDC0508I DATA ALLOCATION STATUS FOR VOLUME G30261 IS 0
IDC0508I DATA ALLOCATION STATUS FOR VOLUME * IS 0
IDC0508I DATA ALLOCATION STATUS FOR VOLUME * IS 0
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME G30261 IS 0
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME * IS 0
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME * IS 0
IDC0181I STORAGECLASS USED IS STANDARD
IDC0181I MANAGEMENTCLASS USED IS MCTLRG
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
It looks like the cleanup is not complete but Level 2 indicated that
some cases like a DEFINE NONVSAM would fail and that we could expect all
the others to fail at some point in the future.
We could only find references to this back in the OS/390 R9 migration
guide. The parameters have been obsolete for a long time and we should
have been more diligent about getting them removed from all jobs after
RACF was implemented to replace Top Secret in the early 90's but a very
few instances linger.
If you are upgrading from z/OS R4 consider to run scans against all your
SYSIN libraries looking for the security-related parameters (READPW,
UPDATEPW, MASTERPW, CONTROLPW, ATTEMPTS, CODE, AUTHORIZATION) and if
found get them removed from use. We were told only one other site had
even queried about this so the expectation from IBM DFSMS level 2
experience is that this doesn't impact very many sites or they are just
to embarrassed to admit it:-) Since z/OS R4 is a big jumping off point
for many sites I think the z/OS R5 and R6 migration guides should have
highlighted this.
Best Regards,
Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
Murphy's Computer Law 30: Program complexity grows until it exceeds the
capability of the programmer who must maintain it.
<>
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
