Re: Problem starting DHCP on V4R4M0 -- MIDRANGE-L

Neil,

Sorry about the delay in follow-up but had to get back on-site.

Yes the error is TCP5721.
No they don't use DBCS.
The default CCSID is 37.
The adopted user profile was a member of QSECOFR.
BOOTP is not started/used.

I will check the cross-ref for PTF SF46518 to V4R4. I would have thought that by
now it would be on the Cum.

Thanks,

Roger Vicker, CCP

Neil Palmer wrote:

> I seem to recall a problem on V4R4 in starting servers (client access &
> TCP I believe) under the QSECOFR profile (which we were doing in the
> startup program which was owned by QSECOFR).
> I can't tell for sure if this is the same problem as you left out the most
> important thing from your joblog excerpt - the message id !  :-)
> Was it TCP5721 by any chance ?
> The error code 3401 does sound familiar for some reason.
> There was a PTF to solve the issue.  The circumvention for us was to
> change the ownership of the startup program to another profile (other than
> QSECOFR) with *ALLOBJ authority.
>
> I did find one PTF reference to TCP5721, but it was related to a problem
> when the job was using DBCS CCSID 290.
> The circumvention was to run the start command from a job with a different
> CCSID (37 was recommended).
> That was fixed in V4R2 with PTF SF46518.
>
> ...Neil
>
> "Roger Vicker, CCP" <rvicker@vicker.com>
> Sent by: owner-midrange-l@midrange.com
> 2001/03/05 16:21
> Please respond to MIDRANGE-L
>
>
>         To:     Midrange List <MIDRANGE-L@midrange.com>
>         cc:
>         Subject:        Problem starting DHCP on V4R4M0
>
> Hello,
>
> Has anyone had a problem (and hopefully a solution) with DHCP not
> starting automatically (CHGDHCPA AUTOSTART(*YES)) and not being able
> to start it manually/explicitly  with adopted authority? I have a
> customer that wants to use DHCP but can only get it to start by being
> a member of QSECOFR. We have tried a program that adopts QSECOFR
> without any success.
>
> The job log shows:
>  From module . . . . . . . . :   QTODDCNV
>  From procedure  . . . . . . :   qtod_IssueMessage__FPcT1ie
>  Statement . . . . . . . . . :   852
>  Message . . . . :   DHCP attributes file missing or not valid.
>  Cause . . . . . :   DHCP requires an attributes file.  The file that
> it tried
>    to open was /QIBM/USERDATA/OS400/DHCP/DHCP.ATTRIB, and it
> encountered an
>    error.  The error code was 3401.  An error code of 0 indicates that
> the DHCP
>    attributes file exists but that the data was not valid. Any other
> error code
>    indicates a file I/O error occurred. Because of this error, an
> attempt was
>    made to restore the attributes file from default values but that
> was
>    unsuccessful also. Without the attribute information, processing
> was unable
>    to continue. Recovery  . . . :   Use the command "WRKLNK
>    '/QIBM/USERDATA/OS400/DHCP/DHCP.ATTRIB'" and if the DHCP attributes
> file
>
> Authority is:
>                    Data
> Opt  User        Authority
>
>      *PUBLIC     *RX
>
> However I did check the full path and found:
>
>                    Data
> Opt  User        Authority
>
>      *PUBLIC     *EXCLUDE
>      QSECOFR     *RWX
>      QTCP        *RX
>
> Thanks,
>
> Roger Vicker, CCP
>
> --

--
*** Vicker Pony Farm *** www.vicker.com/vicker/vpf.html ***
Where do you find 100 talking invertebrates? The US Senate


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---