|
Bill, It seems you just replicated the situation that I had. But like I mentioned, I am a new operator (although I have been exposed to AS/400's as a user for 10 years) and would not know where to start with IBM. Since the only thing that seems broken is a printout, I am going to work around this. Thanks for verifying it! -----Original Message----- From: Bill Roha [SMTP:Broha@stantinc.com] Sent: Wednesday, April 19, 2000 9:13 AM To: MAPICS-L@midrange.com Subject: RE: What's up with all these data areas as owned objects by myself? Dave's right; I spoke too soon. Most of our programmers (who start the unattached jobs) have objects owned by QPGMR. QPGMR owns 7176 objects (as shown on the printout.) which matches the objects created in the outfile. But I canceled the printout after 8000+ pages...it was repeating the 5 *DTAARA (ZZFLES, ZZLDA, ZZPRC, ZZRQS, ZZTSK) in QTEMP. There are legitimately 37 such sets of data areas in QTEMP owned by QPGMR, but the report repeats "forever". IBM has fixed related problems (at least in V4R4) with the display of owned objects, but I don't think this one has been reported. Who's going to tell IBM? Bill Roha Stant Manufacturing Inc. broha@stantinc.com 765-825-3121 x440 >>> dshaw@spartan.com 04/19/00 07:39AM >>> Actually, it may be reasonable for it to show duplicates in QTEMP, if there's more than one job running under that user profile. After all, each of those jobs has a QTEMP, and if they're MAPICS jobs, each has copies of the MAPICS data areas that get created in QTEMP when MAPICS initiates. What's not reasonable is for the DSPUSRPRF *PRINT to not match the *OUTFILE, especially since it appears to be looping out of control. That's where the OS/400 bug must be. To check whether the outfile is correct, shut down ALL the jobs running under the user profile in question, then run the DSPUSRPRF *OUTFILE and make sure nothing shows up in QTEMP. Then start one MAPICS job under the profile, and check DSPUSRPRF again. I'd expect to see one set of data areas in QTEMP. Start another MAPICS job, and check again. I'll bet there's two sets of QTEMP data areas at that point. Dave Shaw Spartan International, Inc. Spartanburg, SC > -----Original Message----- > From: Bill Roha [mailto:Broha@stantinc.com] > > If it's in QTEMP it can't have anything to do with the > u-jobs, since they are different jobs. > > Do a DSPLIB QTEMP and see how many objects are there. There > "can't" be duplicates. > > If DSPUSRPRF shows more objects in QTEMP (or duplicated > objects), then I have to think it's an IBM problem. > > The duplicate data areas you see "have" to be in different > libraries. > > The reason *PRINT and *OUTFILE are different is some IBM > error that is very unusual. > > I'd contact IBM. RCLSTG (which someone else suggested) may > fix the problem, but it's a dedicated procedure that takes > "hours". If you have support from IBM, I'd start there. > > Someone else suggested this is a known MAPICS problem, but I > don't see how MAPICS could cause DSPUSRPRF to fail. > > Bill Roha > Stant Manufacturing Inc. > broha@stantinc.com > 765-825-3121 x440 > > > > > >>> burnsbm@echoincorporated.com 04/18/00 02:30PM >>> > Same thing happens after signing off. It only happens to me, > tried it on a > MIS programmer and it worked fine. > > This only happens when output is *PRINT. If output is > *OUTFILE, it works > fine and I can create a query showing only 33 data areas > (some repeated > even there too). > > Now I am thinking it is related to the five u-jobs that have > my name on > them... > > But why isn't *PRINT and *OUTFILE the same?? > > > > > -----Original Message----- > From: Bill Roha [SMTP:Broha@stantinc.com] > Sent: Tuesday, April 18, 2000 1:11 PM > To: MAPICS-L@midrange.com > Subject: Re: What's up with all these data areas as > owned objects > by myself? > > (I think everyone on this list is "gentle"). > > The objects you list (at least most of them) are created > when you go > into MAPICS. As you may know, QTEMP is a temporary library > for your job > that is created when you sign on (everybody has their own.) > > I'd sign off and on and try the DSPUSRPRF again. If it > works, there > was some transient IBM error. If it doesn't, there is some > more serious > error with IBM's DSPUSRPRF. (I did the same command as you > did and didn't > have any difficulty, so if there is a "permanent" problem for > you, it is > because of some "strange" condition at you site.) > > I don't know if you noticed, but it appears that you've > listed several > objects multiple times. You can't have duplicate object names in a > library, so if they are really showing on the printout > multiple times for > one library, it appears that DSPUSRPRF is confused. > > So sign off, sign on, go to MAPICS, try DSPUSRPRF again. > If it fails > like it did before, decide if it's worth the effort to report > it to IBM. > (But I'd be interested in knowing in either case.) > > Bill Roha > Stant Manufacturing Inc. > broha@stantinc.com > 765-825-3121 x440 > > > > > >>> burnsbm@echoincorporated.com 04/18/00 10:18AM >>> > Hello everyone, > > I did a DSPUSRPRF USRPRF(myself) TYPE(*OBJOWN) OUTPUT(*PRINT) and the > AS/400 generated 10,000 pages and was still chugging along > when I killed > the job with a system request. Although the top of the > report says I own a > total of 145 objects, the report kept listing MAPICS data > areas over and > over. At 50 records a page, the report had about 500,000 > records and was > still generating when I killed the job. Funny thing is, if I > do the same > DSPUSRPRF to an outfile, I only get 33 data areas! > > I imagine this is not something I need to get concerned > about, but it all > about because I had forty AS/400 user profiles that I needed > to delete and > I started looking at object ownership by user profiles. > > Does anyone have any ideas as to what is happening here? > These are MAPICS > data areas aren't they? I suspect it is related to me being > the one who > schedules MAPICS back ups. > > Please be gentle as I am only a lowly operator running MAPICS > XAR2 (soon to > be 5.5) on a V4R4 620. > > Here is a sample of part of the report: > Object Library Type > ZZMNU QTEMP *DTAARA > ZZSTRM QTEMP *DTAARA > WND_1024 QTEMP *USRSPC > ZZFLES QTEMP *DTAARA > ZZLDA QTEMP *DTAARA > ZZPRC QTEMP *DTAARA > ZZRQS QTEMP *DTAARA > ZZTSK QTEMP *DTAARA > ZZFLES QTEMP *DTAARA > ZZLDA QTEMP *DTAARA > ZZPRC QTEMP *DTAARA > ZZRQS QTEMP *DTAARA > ZZTSK QTEMP *DTAARA > ZZFLES QTEMP *DTAARA > ZZFLES QTEMP *DTAARA > ZZLDA QTEMP *DTAARA > ZZPRC QTEMP *DTAARA > ZZRQS QTEMP *DTAARA > ZZTSK QTEMP *DTAARA > CMDSTK QTEMP *DTAARA > DGMNU QTEMP *DTAARA > ZZFLES QTEMP *DTAARA > ZZIFM2 QTEMP *DTAARA > ZZLDA QTEMP *DTAARA > ZZMCNT QTEMP *DTAARA > ZZMNU QTEMP *DTAARA > ZZSTRM QTEMP *DTAARA > WND_1024 QTEMP *USRSPC > ZZFLES QTEMP *DTAARA > ZZLDA QTEMP *DTAARA > ZZPRC QTEMP *DTAARA > ZZRQS QTEMP *DTAARA +--- | This is the MAPICS Mailing List! | To submit a new message, send your mail to MAPICS-L@midrange.com. | To subscribe to this list send email to MAPICS-L-SUB@midrange.com. | To unsubscribe from this list send email to MAPICS-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dshaw@spartan.com +--- +--- | This is the MAPICS Mailing List! | To submit a new message, send your mail to MAPICS-L@midrange.com. | To subscribe to this list send email to MAPICS-L-SUB@midrange.com. | To unsubscribe from this list send email to MAPICS-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dshaw@spartan.com +--- +--- | This is the MAPICS Mailing List! | To submit a new message, send your mail to MAPICS-L@midrange.com. | To subscribe to this list send email to MAPICS-L-SUB@midrange.com. | To unsubscribe from this list send email to MAPICS-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dshaw@spartan.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.