ca.portal.admin

Error Status 1410 (subschema/access restriction) on Unsecured

Discussion created by ca.portal.admin on Aug 18, 2009
Latest reply on Aug 18, 2009 by ca.portal.admin
Dialog


Hello All,

We are getting an IDMS error status 1410 on an unsecured dialog. The dialog
has worked happily for years without a user signon. Now, after a change,
the dialog works only if a user is signed on, and gets the 1410 if no user
is signed on.

For a 1410 the manual specifies access restrictions on the subschema and
that perhaps the subschema has changed since the dialog was compiled. There
has been a change involving subschemas, but we just can't figure out what's
causing the 1410. Here is a brief description of the change:

Control is transferred to this dialog (dialog B) with an EXECUTE NEXT
FUNCTION from dialog A. Previously, dialogs A and B both used the same
subschema, but dialog B now needs additional data, so a new subschema was
created which is solely used by dialog B. Both subschemas and dialogs have
been recompiled multiple times and new-copied in the proper sequence.
Because of the signon / non-signon issue and because the manual indicates
that this could be related to an access restriction in the subschema we are
looking into security issues. But where to look? We only have application
security (no table/row security). Racf is used only for initial
authentication. Is this related to subschemas at all?

Any suggestions are appreciated.

Jerry


More details if anyone is still with me....


CA-ADS RELEASE 16.0 *** DIALOG ABORT INFORMATION ***
ABRT
DC173001 APPLICATION ABORTED. SUBSCHEMA BIND FAILED; STATUS=1410
DC466004 Unable to display source. Error status= 1410

DATE....: 09.230 TIME....: 09:34:20.60 TERMINAL....: VTLD315

ERROR OCCURRED IN DIALOG......: SGNI300D
AT OFFSET......: 1DC8
IN PROCESS.....: PM-SGNI300D VERSION:
1
AT IDD SEQ NO. : 00017200

SEQUENCE
NUMBER: SOURCE :
00000000
00017200
00000000


Dialog A's subschema (used in the calling dialog - this one works):

SUBSCHEMA NAME IS PSSGNINP OF SCHEMA NAME IS DCPIAPRD VERSION IS 1
PUBLIC ACCESS IS ALLOWED FOR ALL
USAGE IS MIXED
.
ADD
AREA NAME IS PSCARD-IX-AREA
.
ADD
AREA NAME IS PSSIGN-AREA
.
and so on...

:
Program Name PSSGNINP Version 1
Type SUBSCHEMA Type DICTIONARY
Language ASM Dictname
Size (bytes) 00003284 Dictnode
ISA size 00000000 Database key 00000324:001
Status ENABLED AND INSRV Storage Prot YES
Dynamic ALLOWED Residence IN POOL AT 12AAD000
Reusable YES Threading CONCURRENT
Reentrant FULLY REENTRANT Overlayable NO
Tasks use ct 000 New Copy ENABLED
Times called 00006199 Times loaded 000001
PGM chk thrh 005 Pgm check ct 000
Dump thrh 000 Dump ct 000
Amode ANY Rmode ANY
PDE address 11E0808C MPmode SYSTEM
Savearea NO Mult Enclave


Dialog B's subschema (used in the called dialog - this one gets 1410):

SUBSCHEMA NAME IS PSSIGN1P OF SCHEMA NAME IS DCPIAPRD VERSION IS 1
PUBLIC ACCESS IS ALLOWED FOR ALL
USAGE IS MIXED
.
ADD
AREA NAME IS PSCARD-IX-AREA
.
ADD
AREA NAME IS PSPERSON-AREA
.
And so on...


Program Name PSSIGN1P Version 1
Type SUBSCHEMA Type DICTIONARY
Language ASM Dictname
Size (bytes) 00004836 Dictnode
ISA size 00000000 Database key 00029831:004
Status ENABLED AND INSRV Storage Prot YES
Dynamic ALLOWED Residence IN POOL AT 12F0D800
Reusable YES Threading CONCURRENT
Reentrant FULLY REENTRANT Overlayable NO
Tasks use ct 000 New Copy ENABLED
Times called 00000310 Times loaded 000001
PGM chk thrh 005 Pgm check ct 000
Dump thrh 000 Dump ct 000
Amode ANY Rmode ANY
PDE address 11DFD2E0 MPmode SYSTEM
Savearea NO Mult Enclave
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Error Status 1410 (subschema/access restriction) on Unsecured Dialog
"This is probably way off base, but are there any security classes coded in
the ADSA definition that now need to be applied to the new subschema that
dialog B is using?

If the EXEC NEXT FUNCTION results in a LINK (ie - the Control Command
defined in ADSA that gets from dialog A to B), is it possible that the new
subschema for dialog B also needs to be made accessible by dialog A? This
might be true especially if the i.o causing the 1410 is in the premap of
dialog B.

Sorry if this muddies the water. I am not great with security, but have had
issues around ADSA security, and thought it might be worth checking.

Outcomes