RE: What's up with all these data areas as owned objectsby myself? -- MAPICS-L

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
+---