Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 983
  • Last Modified:

ODBC data source not showing fields after OS upgrade

I upgraded an iSeries from V6R1 to V7R1 this weekend.   This morning, a UPS shipping machine had trouble reading the ODBC data source.   I got on tonight thinking that this would be easy.  I tested with MSQRY32.  I connect to the iseries fine.  I can see the libraries and the files.  But I dont see the fields.   I upgraded iSeries access to v7r1.   I applied the latest service pack.   I deleted the *SQLPKG files from the 400.   Im coming up empty now.   I would really appreciate any ideas.
0
Jon Snyderman
Asked:
Jon Snyderman
  • 2
  • 2
2 Solutions
 
Gary PattersonVP Technology / Senior Consultant Commented:
Are you getting an error?  When you or the UPS jobs connects, it will be assigned to a QZDASOINIT (QZDASSINIT if you use SSL) job.  That job log will generally have any errors in in.

One way to find the right QZDASOINIT job is to establish a connection, try something that fails, and them log onto a green screen and do a

WRKOBJLCK yourprofilename *USRPRF

Where yourprofilename is the name of your IBM i user profile (or the profile UPS uses).

That's because when a job logs on, it automatically grabs a shared read lock on the user profile associated with the job.

So once you find the QZDASOINIT job, display the job log, press F10 to see detailed messages, look for error messages, and if you find any, put your cursor on each one in sequence and hit F1 to display the full message detail.

Post the full message detail (sometimes it runs to a couple of pages) for each message you find that looks like it might be related to the problem.  Sometimes the message will provide recover actions.  Try those and post any positive or negative results.
0
 
Jon SnydermanAuthor Commented:
Thanks Gary.   I ended up having to call IBM and we believe that we tracked it down to DB cross reference files.   I am going to run a RCLSTG tonight and see if that helps.   I am going to take a look at those job logs also.

Thanks!
0
 
Gary PattersonVP Technology / Senior Consultant Commented:
Yeah, we've had that happen.  

RCLSTG SELECT(*DBXREF) usually fixes it.
0
 
tliottaCommented:
Using RCLDBXREF OPTION(*CHECK) first should be the best first step. If it reports problems, then run RCLDBXREF OPTION(*FIX).

If RCLDBXREF clears the problem, then RCLSTG SELECT(*DBXREF) can be postponed to a more convenient time. (It should still be run.) The RCLDBXREF command is much nicer to use than RCLSTG since it can run at any normal time.

It generally runs quickly enough to keep everyone happy, especially operations staff. Expect 15 mins to half an hour, but I've seen it faster. All depends on... well, a lot of stuff.

Tom
0
 
Jon SnydermanAuthor Commented:
Hi Tom,

Yes, we ran the RCLDBXREF prior to coming to the conclusion to run the RCLSTG.   This is a small quick system.  I ran the *DBXRF after hours and it literally took about a minute.    

Thanks to both of you.

Jon
0

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now