Joined: 31 Mar 2008 Posts: 29 Location: Kuala Lumpur
Hi Joerg,
We have followed this link and not supress record type 133 but the same message still appears. We are using X11 and unable to set the parameter to 'NO'. The display odf our SMF as below:
You already have 133 in the SMFPRMXX, it is possible that Connect Direct requires 132 as well. Worth a shot. Can you include 132 in the SMFPRMXX.
Given that you are upgrading and not installing it afresh, this error should have appeared in previous version as well. Is there any chance you enabled Statistics exit during the upgrade?
Joined: 31 Mar 2008 Posts: 29 Location: Kuala Lumpur
We got another message SITA997I Security Environment Invalid for Connect:Direct.. Is this link to SITA386E SESSION.HIGHWATER.SMF records are not being recorded?
Security Environment Invalid for Connect:Direct.
Connect:Direct is running in a RACF Program Control
environment, but the JOBLIB/STEPLIB/LINKLIB DSNs from which C
modules were fetched are not in the Program Control list.
Either turn off Program Control, or place all the
JOBLIB/STEPLIB/LINKLIB DSNs in the appropriate RACF table.
Joined: 31 Mar 2008 Posts: 29 Location: Kuala Lumpur
After we add in all JOBLIB/STEPLIB/LINKLIB DSNs in the appropriate RACF table. the problem resolved. Now another problem with below messages:
SITA121I Keyword not Specified in INITPARMS: AUTHDSN
SITA121I Keyword not Specified in INITPARMS: CKPTDSN
SITA121I Keyword not Specified in INITPARMS: MSGDSN
SITA121I Keyword not Specified in INITPARMS: NETDSN
SITA121I Keyword not Specified in INITPARMS: TYPEDSN
SITA123I REQUIRED initparm is not set, terminating.
If you have the ConnectDirect product licensed then you should have access to the manual. Whatever the parmlib is in the started task JCL obviously needs these parm's added, and the manual should explain the syntax and meaning of each one.
On the EXEC in the C : D started task proc it has
PARM=('DSN.PARMLIB(MEMBER))','&PRM')
In that parmlib member you specify the dataset names that relate to each keyword where DSN below is whatever your
C : D set up uses for the HLQ etc, probably the same HLQ as names specified on the DMPUBLIB and ONLYONE DDnames in the STC proc. Just find the names of the datasets with the correct suffix to match the keyword
However, we still having same messages. Just wonder PGM=DGADINIT unable to recognise the keyword for the initparm. Should we maintain any other libraries in CLIST or Linklib?
Joined: 31 Mar 2008 Posts: 29 Location: Kuala Lumpur
Hi, managed to resolved the problem as we took the initparm from V5.2 and changed according to V6.3 datasets/VSAM file for V6.3. We were able to start the CD server/Starter task, but got message as below:
My starter task is ACCDZ63T and We believed the ACCDZ63T should be granted some permission to the TCP but we just can't indentify what to be granted? Anyone got idea? If we renamed the starter task to our old V5.2 starter task name, we were able to start the CD server 6.3.
Joined: 31 Mar 2008 Posts: 29 Location: Kuala Lumpur
Manage to bring up the starter task after define the port 1364 for ACCDZ63T. Now. We are able to bring up CD Server/Starter Task.
However, noticte an error message for MSG file during initialization:
SITA067I MESSAGE file is open.
13.33.33 STC72840 SMSG008I GET FOR MSGFILE FAILED. RC=00000008 FEEDBACK=00000010 976
976 SMSG008I KEY=SITA760W(X'E2C9E3C1F7F6F0E6')
What was the status of the MSGFILE when you started the STC? Was it empty, or already populated with some data? It may be finding a duplicate key. or needs initialising if empty. We can't determine this remotely so ask for local site support.
SMSG008I
MODULE =DMGMSGFH
GET FOR MSGFILE FAILED. RC=rr FEEDBACK=fdbk KEY=msgid
A GET request from the Connect:Direct message file failed. The
VSAM return code from a SHOWCB and FDBK code are displayed.
The message ID being looked up is also shown.
SYSTEM ACTION : This message is displayed to the ESTAE DD also.
A return code of 8 is passed back to the module who called
the message file handler. If RC=8 and FDBK=16, an "not found"
indicator is set in the caller's PLIST
RESPONSE: Gather the output from the ESTAE DD and the system
log. Look up the system log messages in the IBM manuals and
determine what action to take. If unable to ascertain an action
contact IBM Support after gathering the log and ESTAE DD output
Joined: 31 Mar 2008 Posts: 29 Location: Kuala Lumpur
After we redefined the MSG file we managed to bring up the CD server/Starter TASK. As we are running 5655-X11 the HIGHWATER.SMF messages keep coming out from the starter task log. Fyi, we comment off the HIGHWATER.SMF for initparm,otherwise the starter would not able to be started giving errror
SITA386E SESSION.HIGHWATER.SMF records are not being recorded - SMFRTEST RC=36
Anyone have encountered similar problem? Although we have defined the Rec TYPE = 133 in SMF as advised by IBM, but the problem still persist.
This very site specific so you need to talk to your local System Programmers. Your SMF type 133 may be suppressed for some reason, perhaps it's used by another product. We can't determine that. Below is an excerpt from the manual and the D SMF command they advise to use would be a good start to see if TYPE 133 is actually suppressed.
SESSION.HIGHWATER.SMF = (133 | 128-255, 1-60) | NO
Last Updated: 2023-01-25
This parameter determines the SMF record type number and the recording interval for High Water Mark records. For License permitting the acceptable range is (133 | 128-255, 1-60). The default value is (133 , 60) where the second value is in minutes.
If the SMF record id of 133 is being used by other applications, you must specify a suitable record id with this initialization parameter. The value of NO is only valid for license versions X01 and X12. X09 and X11 licenses require the SESSION.HIGHWATER.SMF parameter.
If message SITA386E or SITA386W appears, it means the default or specified record type is being suppressed by SMF. Refer to D SMF, O display and look for NOTYPE sub parameter of the SYS parameter to see which records are being suppressed.
Joined: 31 Mar 2008 Posts: 29 Location: Kuala Lumpur
Hi Pete,
I have talked to our system programmer and IBM Support but they still have no idea why these messages keep coming out. We didn't suppress TYPE=133 as you could see my D SMF, O display as follows:
