ca.portal.admin

Re:Re: IDMS @ TDMF

Discussion created by ca.portal.admin on Jul 20, 2006
Hi Dave,
We make extensive use of TDMF and have not had any problems with it.
We are just coming to the end of a data centre consolidation project
where we have moved well over 50 CV's from one data centre to another
using TDMF. The CV's, which are very busy, were up and running during
the transfers and we have not had any problems.

The only time I have seen a problem was when we used it on a failing
box, moving the volumes off to a good box without having to take the
service down. The disk performance, which was very poor anyway, took a
further hit which caused IDMS problems - but I have never seen a
problem
when using it against a good device.

I also used LDMF for the first time a few weeks ago. This lets you
move
individual files whilst IDMS is still accessing them. Again no
problems.


Regards,
Steve

Steve Terry
BT

'This post represents the views of the author and does not necessarily
accurately represent the views of BT.'
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000

This electronic message contains information from British
Telecommunications plc which may be privileged and confidential. The
information is intended to be for the use of the individual(s) or
entity
named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic
message
in error, please notify us by telephone or e-mail (to the number or
address above) immediately.
We are using TDMF to copy our system from one set of dasd to another
set of
dasd. Has anyone out in IDMS land had any positive, negative or
neural
experiences with using TDMF to move idms database while the database
is
up
and running?



David Brenner

IDMS SYSTEM PROGRAMMER

ACS

2828 N. Haskell

Dallas, TX 75204

214-841-6492

David.Brenner@acs-inc.com <mailTo:David.Brenner@acs-inc.com>

This E-Mail has been scanned for viruses.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Business functionality extraction tool
"Does anyone know of a tool that will extract the business functionality/logic
from an ADS dialog? I am NOT looking for an automated conversion tool, but
simply a tool that will take in ADS source and output the business
functionality/logic. I've seen a few that will perform this for COBOL. Please
reply directly to my email address

lindajcasey@comcast.net

Thanks in advance,
Linda Casey
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Business functionality extraction tool
"At 16:49 7/24/2006, you wrote:
Does anyone know of a tool that will extract the business functionality/logic
from an ADS dialog? I am NOT looking for an automated conversion tool, but
simply a tool that will take in ADS source and output the business
functionality/logic. I've seen a few that will perform this for
COBOL. Please
reply directly to my email address

lindajcasey@comcast.net

Thanks in advance,
Linda Casey
i was looking for a package like that too, but then i realized there
was no logic in anything I wrote .....
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
R15 CVs CICS Transactions Coming From R16 CIYUH/CICSB to R15 CV HWIDMSSA/HWIDMSB Abending in RACF
"Hello,



We just upgraded a couple of CVs recently from R150109 to R16 SP3. We are
experiencing various problems.

This is one of them.



1. When we execute a CICS application program from a CICS region that is
using Release 16 CINT/INTC interface

and the program attempts to connect to a R15 CV we receive a 1469 abend
following this USER(PUBLIC) GROUP(EXTERNAL)

revoked user access attempt.

2. The same CICS application from a CICS region that is using R15 CINT/INTC
interface and R15 CVs is not having the problem

3. Tthe same CICS application from a CICS region that is using R16 CINT/INTC
interface and R16 CVs is not having the problem.


HELP!

ICH408I USER(PUBLIC ) GROUP(EXTERNAL) NAME(WEB SERVER SAMPLE ID) 616


LOGON/JOB INITIATION - REVOKED USER ACCESS ATTEMPT


+IDMS DC201006 V61 T1 CV-Status  BE-TaskID Pri FE - ID1 FE - ID2 FE TaskCD
FE Us

+IDMS DC201006 V61 T1 ABRT SNON        380 100 CCUHBULK LTERM001 U163
PUBLI

ICH408I USER(PUBLIC ) GROUP(EXTERNAL) NAME(WEB SERVER SAMPLE ID) 885


LOGON/JOB INITIATION - REVOKED USER ACCESS ATTEMPT


+IDMS DC201006 V61 T1 CV-Status  BE-TaskID Pri FE - ID1 FE - ID2 FE TaskCD
FE Us

+IDMS DC201006 V61 T1 ABRT SNON        381 100 CCUHBULK LTERM001 U163




Multiple item definitions exist for this item
<<<<<<<<<


****************************************************************************
*

ICH408I USER (userid) GROUP (group-name) NAME (user-name) or JOB


(jobname) STEP (stepname) {SUBMITTER (userid)} {resource-name}


{CL(class-name)} or {VOL(volume-id)}


{FID(file-identifier)} {ID(IPC-identifier)} or {FROM


generic-profile-name (G)} {ACCESS INTENT(intent) ACCESS


          ALLOWED(allowed)} {EFFECTIVE UID (nnnnnnnnnn} {EFFECTIVE GID


          (nnnnnnnnnn}





Explanation: This message is issued when RACF detects an


unauthorized request (a violation) made by a user or job. The user


and group indicated in the first line of the ICH408I message are


the execution user ID and group ID under which the job was to run.





If the message indicates a job and step instead of a user, group,


and name, RACF could not find a valid ACEE containing user, group,


and name, RACF could not find a valid ACEE containing user, group,


and name information. This could occur for a started task that is


not defined in the RACF started procedures table (ICHRIN03), if an


entry in the started procedures table has an incorrect RACF group


specified, or if the user's ACEE has been corrupted. If the


submitting user ID is not the same as the execution user ID, the


message includes an additional line containing the submitting user


ID, group, and node.





FWhen the message is reporting an access failure for an z/OS UNIX


file, the resource name is the pathname that was specified to the


kernel syscall. It will not exist for the syscalls performed


against open files (those in the ""fxxxxx"" format such as fchown).


The FID (file identifier) is a unique 32-hex-digit identifier of


the file. It is provided because multiple pathnames can be used to


access the same file. This identifier will allow matching of


accesses to the same file by different names.





When the message is reporting an access failure for an z/OS UNIX


IPC key, the resource name is the IPC key name that was specified


to the kernel syscall. It is displayed as a unique 8-hex-digit


identifier. The ID (IPC identifier) is a unique decimal identifier


of the resource. It is provided as additional information, that


may be useful during auditing, although it is dynamically


allocated by the kernel. It is a numeric value between 0 and


4294967295.





The meaning of the volume serial number shown in the VOL field


varies. For a non-VSAM data set, it means the volume on which the


data set resides. For a VSAM data set, it means the volume on


which the catalog containing the data set entry resides.





The phrase FROM generic-profile-name (G), if included in the


message, identifies the generic profile that RACF used to check


for access to the resource.





For further explanations of this message, check the message line


that indicates what request was made. This is usually line 2 or 3.


For example, it could be INSUFFICIENT ACCESS AUTHORITY. Find this


message line among the explanations that follow for message


ICH408I (arranged alphabetically), and read the explanation for


that message line.





For attempts to use protected resources, the message shows the


access attempted (ACCESS INTENT phrase) and the access permitted


by RACF (ACCESS ALLOWED phrase). When the message is reporting an


attempt to access an z/OS UNIX file or IPC key, the ACCESS INTENT


(intent) is specified as ""RWX,"" representing read, write or


search/execute permission requested. More than one permission can


be requested at a time. If a permission is not requested, the


letter is replaced by a dash ""-."" ACCESS ALLOWED (allowed) is


specified as ""{OWNER/GROUP/OTHER/ACL USER/ACL GROUP/NO/RESTRICTED}


RWX,"" where OWNER indicates the owner permission bits were used,


GROUP indicates the group permission bits were used, OTHER


indicates the other permission bits were used, ACL USER indicates


GROUP indicates a specific group ACL entry (or entries) was used,


NO indicates that no permission bits were used, RESTRICTED


indicates the OTHER bits were not used for a RESTRICTED user, and


""RWX"" represents the settings of the permission bits that were


checked. ACCESS ALLOWED (NO --X) occurs if a superuser attempts to


execute a file that does not have OWNER, GROUP, ACL, or OTHER


execute permission. ACCESS ALLOWED (RESTRICTED ---) occurs if a


RESTRICTED user could have only gained file access via the OTHER


bits, but the RESTRICTED.FILESYS.ACCESS profile in the UNIXPRIV


class has forbidden this.





Note that while checking for group access, the group permission


bits are treated as simply another GID ACL entry, if the process


GID, or one of its supplemental GIDs matches the file owner GID.


Several group entries may actually be checked, and access will be


granted if any of them specifies the requested permissions.


However, if none of the entries grants the requested access, there


is no single entry that defines the access allowed. By convention,


the permissions associated with the first relevant group entry


encountered are what will be displayed in the message. See the


z/OS UNIX information in the z/OS Security Server RACF Security


Administrator's Guide for a description of the algorithm used to


determine access when an ACL exists for a file or directory.





For violations occurring in the UNIX System Services environment,


the user's effective UID and effective GID are displayed in the


message. These ids were used to determine the user's privilege


for the intended operation. Note that they may not always match


the ids defined in the relevant RACF USER and GROUP profiles,


since UNIX System Services provides methods by which another


identity can be assumed.





System Action: If the phrase RESOURCE NOT PROTECTED appears in


the message with a warning, RACF allows the request to continue.


If the phrase RESOURCE NOT PROTECTED appears in the message


without a warning, RACF fails the request.





Notes:





1. When a user is denied access to a RACF-protected resource


because of the return code from a RACROUTE REQUEST=AUTH


installation exit routine, the user's allowed access may be


inconsistent with the requested access. (For example, access


allowed was ALTER, access requested was READ, but the request


for access was denied.)





2. Authority checking for users with the restricted attribute


bypasses checking of some authority granting mechanisms, such


as the UACC. If a LISTUSER for the user ID shows that the user


is restricted, the user's user ID or group name must be on the


access list to allow access to the resource. See z/OS Security


Server RACF Security Administrator's Guide for additional


information on restricted access user IDs.








3. A user who has ALTER access authority to a DASD volume can


scratch a data set on that volume even if the user does not


have the required ALTER access authority to that particular


data set. In this case, on systems without always-call,


message ICH408I is issued even though the data set is


scratched; on systems with always-call, the message is not


issued.





4. The phrase ""LOGON/JOB INITIATION/initACEE"" may appear during


logon processing; however, the logon may be successful. When


RACF is active, logon verification can produce an error during


RACF processing; however, the logon can proceed using an


alternate method (for example, UADS). This error occurs if the


installation does not use the RACF database to store


security-related information for a particular user, but it


does use an alternate method (such as UADS) for the logon


application (for example, TSO) to perform user verification.








5. If the failure occurred for a z/OS UNIX System Services system


function, RACF returns an error return code to the invoking


system function, which will return an error return code to the


application caller or will cause the calling task to abend.


See z/OS UNIX System Services Programming: Assembler Callable


Services Reference to determine the action of the syscall


functions.





6. If you see JOB/STEP, it indicates a default security


environment for an undefined user. This can happen if a


started procedure is not defined correctly in the STARTED


class or in ICHRIN03.





o If you used the STARTED class, make sure it was properly


RACLIST REFRESHed after you added the profiles.





o If you used ICHRIN03, be sure to IPL the system with CLPA.





User Response: Follow the security procedures established for


your installation. If no such procedures have been established,


report the complete text of this message to the RACF security


administrator.





Operator Response: Follow the security procedures established for


your installation. If no such procedures have been established,


report the complete text of this message to the RACF security


administrator.





Problem Determination: Detailed information about the violation


is available in the SMF type 80 record that RACF produces at the


same time as this message. See z/OS Security Server RACF Auditor's


Guide for information about reporting on the contents of the RACF


SMF records.





Notes:





1. When RACF verifies a password during logon or when a batch job


begins, the message includes NAME (???).





2. For users not defined to RACF, the job and step are indicated


by jobname and stepname. For batch users, stepname is blank.





Destination: Descriptor code is 4. Routing codes are 9 and 11.


This message is routed to the security console. All violations


(except LOGON/JOB initiation/initACEE messages, command


violations, and z/OS UNIX System Services violations) are issued


as write-to-programmer (WTP) messages.





Note: A TSO/E user who is using z/OS UNIX System Services does


not see the ICH408I messages.


****************************************************************************
*
Multiple item definitions exist for this item
<<<<<<<<<

****************************************************************************
*
















Carol McLaughlin
Employment Development Department
Information Technology Branch
Production Operations Management Division
Database Group
Integrated Database Management System (IDMS) Team
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: R15 CVs CICS Transactions Coming From R16 CIYUH/CICSB to R15 CV HWIDMSSA/HWIDMSB Abending in RACF
"From the 16.0 Security Admin. Book:

B.3.8 USER

Topic lines 107 to 121
of 138
Special record occurrences: These are special occurrences of the
USER
record:





t Group 'PUBLIC' -- created on the first grant of privilege to
PUBLIC
(group 'PUBLIC' cannot be dropped):



AUTHID: 'PUBLIC'

TYPE: 'G'

STATUS: (space)

PASSWORD: (spaces)

NAME: (spaces)

DESCRIPTION: 'System Category bit map owner'

PROFILENAME: (spaces)

CUSER: 'SYSTEM'

B.3.8 USER

Topic lines 122 to 136
of 138
UUSER: 'SYSTEM'

Other fields as noted in the USER record description above





t User 'SYSTEM' -- created by the first CREATE RESOURCE CATEGORY

statement (user 'SYSTEM' cannot be dropped):



AUTHID: 'SYSTEM'

TYPE: 'U'

STATUS: (space)

PASSWORD: (spaces)

NAME: (spaces)

DESCRIPTION: 'PUBLIC Group'

PROFILENAME: (spaces)

CUSER: 'SYSTEM'

B.3.8 USER

Topic lines 137 to 138
of 138
UUSER: 'SYSTEM'

Other fields as noted in the USER record description above


How is your external security setup in SRTT? What's a racf LU show on
these users?

Steve Harmeson

Outcomes