Numerous Job Logs for QZSOSIGN after upgrade from V5R4 to V6R1

2,480 pts.
Tags:
AS/400
i5
iSeries
OS/400
Upgrade from V5R4 to V6R1
Just upgraded our Dev box from V5R4 to V6R1. I am now noticing numerous job logs being generated for QZSOSIGN, Signon Server Job. I can tell by the joblog entries that request is for user Qsecofr, how do I track it back to what job is actually making this request ?

Software/Hardware used:
OS/400, V6R1, i5
ASKED: June 24, 2010  3:01 PM
UPDATED: October 26, 2011  7:04 PM

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 12  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    Check your Management Central activities. Look for various monitors that might be started or actions that are scheduled. Review the joblog for the QYPSJSVR job to see what timestamps are on messages and compare them against connections to *SIGNON. QSECOFR is used within MgtC to connect to the database, to connect to the remote command server and various other processes. MgtC can schedule a lot of activities. You might consider changing the *SIGNON server job description not to produce spooled joblogs for normal termination. Tom
    125,585 pointsBadges:
    report
  • wpoulin
    Tom, It does appear that MgtC is the culprit, the times appear to match activity in the Qypsjsvr Job. The Qypsjobd is set to 4 0 *nolist and the jobd end code is 0. Why is a job log being produced ? Thanks, Bill Poulin
    2,480 pointsBadges:
    report
  • TomLiotta
    The Qypsjobd.... Why is a job log being produced ? Heh... I thought the question was about "QZSOSIGN, Signon Server Job". Tom
    125,585 pointsBadges:
    report
  • wpoulin
    Tom, It is about QZSOSIGN, when I look at the job log it is running under the Qypsjobd, which is set to 4 0 *nolist and the job end code is 0. I would have thought that no job log would have been completed. Hopefully this clarifies my question, Thanks, Bill Poulin
    2,480 pointsBadges:
    report
  • TomLiotta
    Ah! Do you have subsystem QUSRWRK running? Are these BCI jobs rather than PJ? Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    If these are BCI jobs and you can find any that are currently active, DSPJOB and review the Job Definition Attributes. Compare the logging level of the active job to the setting on the *JOBD. Do they match? Tom
    125,585 pointsBadges:
    report
  • wpoulin
    Tom, They do not match. The Jobd, Qypsjobd, is set for 4 0 *Nolist. The Job Log records a setting of 4 0 *Seclvl, and it is using Qpysjobd as a Jobd. Where do you think this is being set ? Thanks, Bill Poulin
    2,480 pointsBadges:
    report
  • wpoulin
    Tom, Just a keying error on my previous post. The Jobd I am referring to is Qypsjobd in both cases. Thanks, Bill Poulin
    2,480 pointsBadges:
    report
  • TomLiotta
    Where do you think this is being set ? Although a *JOBD can provide a default value. The actual value could come from SBMJOB JOB() or CHGJOB JOB() or possibly elsewhere. For a BCI job, I haven't run across a description. My first guess would be to look at the job that caused the BCI job to run. On the first system I checked, the QYPSJSVR job (i.e., MgtC) was running at LOG(4 0 *SECLVL) even though the *JOBD is LOG(4 0 *NOLIST). MgtC possibly runs CHGJOB to force a logging level for itself under some conditions. That makes me suspect that a BCI job could inherit from the invoking job. If your system also has job QYPSJSVR running at (4 0 *SECLVL) in spite of its *JOBD, then we have another data point. Tom
    125,585 pointsBadges:
    report
  • wpoulin
    Tom, Qypsjsvr is running and is set at 4 0 *Seclvl. So if this is the job that is doing the submits I can understand that this logging level could be inherited. What I don't understand is that Qypsjsvr is also running on our Production System, still at V5R4, and I don't see all of these BCI Qzsosign job logs. Something has changed with V6R1. Any thoughts ? Thanks, Bill Poulin
    2,480 pointsBadges:
    report
  • TomLiotta
    Any thoughts ? Not enough of them unfortunately. I haven't been involved in startup programming for quite a few releases, so I no longer know the timing requirements. My first step would be to compare the QSTRUPPGM (assuming you use one, which 99.9999% of sites do) between the two systems. Verify the sequence of startups relating to subsystems, TCP/IP, the TCP/IP servers and the host servers. Pay particular attention to the point where MgtC starts and how it relates to the QUSRWRK subsystem and other host servers. Then scan the i 6.1 Memo to Users for discussions about startup programming. IBM has made changes in how and when TCP/IP starts and some related elements. If the startup program needs some rearrangement for 6.1, that might be all there is to it. You might consider delaying a start of MgtC until later in the sequence. Perhaps some tests need to be done before allowing it to start. It may be set to auto-start when TCP/IP starts but QUSRWRK isn't started until later, for example. You should also review Database and Remote Command host server Properties in iNav. Make sure you know how their startup is configured (on both systems) and what their subsystems settings are. I don't have a direct answer, just similar incidents plus enough experience for more speculation than might be good for us. Tom
    125,585 pointsBadges:
    report
  • WoodEngineer
    If this is still an issue, I have a tip from IBM for changing iNav user to something other than QSECOFR. This tip solved the issue of QSECOFR's Previous Signon date and time being updated when we did not want it updated.
    6,045 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following