OK I mis-remembered what occurred.
When copying files from CD to the IFS, make sure you change the object owner once in awhile (every 100,000 entries or so).
Limit the files in each folder also, its difficult to search in a folder with a million entries.
On our iseries (v5r4), an owner can have a max number of owned objects. Many objects were being added as owner PGMR.
Once in the past, the limit was exceeded by copying thousands of docs to an IFS folder with the same owner.
When this limit was exceeded, all production jobs would not start, and no users could sign on. Every job abended, and new jobs would not begin.
OK the iseries was still up, but nothing was running on it. Errors were logging everywhere, with no obvious reason. Not pretty.
Someone figured out to run PRTPRFINT, sure enough an owner exceeded its limit of objects owned.
Only solution was to change object owners on thousands of IFS documents, which takes time.
From a technical perspective, maybe the iseries wasn't down. But from users perspective, it certainly was.
Just trying to give the OP a heads-up if they are contemplating copying millions of documents to their iseries. Not sure of their volume or their release, which would obviously be important considerations.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of J Franz
Sent: Thursday, May 10, 2012 11:05 AM
To: Midrange Systems Technical Discussion
Subject: Re: Compare optical volumes for duplication
Joel,
Can you explain what this statement is based on?
" If it hits max # of entries per owner, it can bring down iseries..."
I suspect this is definitely not true (unless we are talking about a patched
error)
Jim Franz
________________________________
From: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Thu, May 10, 2012 10:37:11 AM
Subject: RE: Compare optical volumes for duplication
Why be concerned about dups? Simply keep each volume in a separate directory on
the IFS.
Not sure what your volume is, but be careful not to put too many files in a
directory. If it hits max # of entries per owner, it can bring down iseries
(assuming you are moving them to iseries but not sure).
Run PRTPRFINT to make sure you are not exceeding limits every so often.
Is part of the project image search and retrieval? This is of course a complex
area - more so than moving files.
We use RJS Webdocs - management & users are very satisfied with the product.
A tool like this can help identify dups along with all the other issues of
document management.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]
On Behalf Of Richard Reeve
Sent: Thursday, May 10, 2012 8:21 AM
To: Midrange Systems Technical Discussion
Subject: Compare optical volumes for duplication
Good morning all,
As part of a project that I have been assigned, I am to migrate images from
a jukebox to dasd. One concern that I have is the possible duplication of
images. There are, for example volumes called RPT01 and one called BKUPRPT01.
How would I go about comparing the saved images and identifying that BKUPRPT01
is in fact a duplication of RPT01? Also, does anyone know how I would be able
to determine if an image was created outside the RDARS application?
Thanks for any advise.
Warmest Regards,
Richard Reeve
midrange.com
