× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: What's up with all these data areas as owned objects by myself?
  • From: "Shaw, David" <dshaw@xxxxxxxxxxx>
  • Date: Wed, 19 Apr 2000 08:39:17 -0400

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.