Library Registration Forms

[Guest.Visitor]

If anyone has a registration form that's given to users when they want to create libraries on a computer system, I'd like to see it. I'm involved in managing several AS400's with a lot of data and disk cleanup and management is difficult. I think that if I had a clear and comprehensive form to provide for folks I'd be able to manage it better. Any help out there? Much appreciated

[David Abramowitz]

On Wednesday, June 09, 1999, 01:14 PM, Frank Bocchino wrote: If anyone has a registration form that's given to users when they want to create libraries on a computer system, I'd like to see it. I'm involved in managing several AS400's with a lot of data and disk cleanup and management is difficult. I think that if I had a clear and comprehensive form to provide for folks I'd be able to manage it better. Any help out there? Much appreciated

---

Here's an alternative: Restrict the CRTLIB command using EDTOBJAUT; This way if anyone wants a library created they will have to go to a specific individual(s). The library creation may be manually controlled in this fashion. David Abramowitz

[Guest.Visitor]

On Wednesday, June 09, 1999, 01:14 PM, Frank Bocchino wrote: If anyone has a registration form that's given to users when they want to create libraries on a computer system, I'd like to see it. I'm involved in managing several AS400's with a lot of data and disk cleanup and management is difficult. I think that if I had a clear and comprehensive form to provide for folks I'd be able to manage it better. One trick I found helpful was not related as much to the creation of libraries as to remembering who they belonged to - large programming environment with several hundred programmers and several machines. There wasn't really a way to enforce control over library creation, although some were better (and most were worse) than others at remembering to let me know if they created something with a non-standard name during a weekend support call. For each system, I created a file that connected each library name to the team name (teams were generally assigned to clients), and team subgroup that had created it. So, the file would look like: SYSTEMA LIBNAMEXX CLIENT123 BILLING SYSTEMA LIBNAMEAB CLIENT123 AR It gave me a single place to look on every system for the origin of each library. I was also able to use this file for sorting reports of disk usage. Regards, Debbie Gallagher

[J.Pluta]

On Saturday, June 12, 1999, 07:09 PM, Debbie Gallagher wrote: One trick I found helpful was not related as much to the creation of libraries as to remembering who they belonged to - large programming environment with several hundred programmers and several machines. There wasn't really a way to enforce control over library creation, although some were better (and most were worse) than others at remembering to let me know if they created something with a non-standard name during a weekend support call. For each system, I created a file that connected each library name to the team name (teams were generally assigned to clients), and team subgroup that had created it. So, the file would look like: SYSTEMA LIBNAMEXX CLIENT123 BILLING SYSTEMA LIBNAMEAB CLIENT123 AR It gave me a single place to look on every system for the origin of each library. I was also able to use this file for sorting reports of disk usage.

---

If your application doesn't require direct access to the CRTLIB command, you can force the issue by restricting authorization to CRTLIB and creating your own NEWLIB command to create libraries (the CPP for NEWLIB would adopt the required authority to the CRTLIB command). This would require entry of the required parameters (and could even verify them) and then would post a record to your library definition file. This way you could also store the user ID and date and time of creation. (BTW, if your applications DO create libraries, you can adopt CRTLIB authority in any programs requiring it, or even better (if practical) change those programs to use the new NEWLIB command). href="//www.zappie.net/java"> src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Zappie's Java Home" align="middle"> Zappie! - where the AS/400 speaks Java with an RPG accent

[Guest.Visitor]

On Saturday, June 12, 1999, 07:39 PM, Joe Pluta wrote: On Saturday, June 12, 1999, 07:09 PM, Debbie Gallagher wrote: One trick I found helpful was not related as much to the creation of libraries as to remembering who they belonged to - large programming environment with several hundred programmers and several machines. There wasn't really a way to enforce control over library creation, although some were better (and most were worse) than others at remembering to let me know if they created something with a non-standard name during a weekend support call. For each system, I created a file that connected each library name to the team name (teams were generally assigned to clients), and team subgroup that had created it. So, the file would look like: SYSTEMA LIBNAMEXX CLIENT123 BILLING SYSTEMA LIBNAMEAB CLIENT123 AR It gave me a single place to look on every system for the origin of each library. I was also able to use this file for sorting reports of disk usage.

---

If your application doesn't require direct access to the CRTLIB command, you can force the issue by restricting authorization to CRTLIB and creating your own NEWLIB command to create libraries (the CPP for NEWLIB would adopt the required authority to the CRTLIB command). This would require entry of the required parameters (and could even verify them) and then would post a record to your library definition file. This way you could also store the user ID and date and time of creation. (BTW, if your applications DO create libraries, you can adopt CRTLIB authority in any programs requiring it, or even better (if practical) change those programs to use the new NEWLIB command). href="//www.zappie.net/java"> src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Zappie's Java Home" align="middle"> Zappie! - where the AS/400 speaks Java with an RPG accent __________________________________________________ ___________________ In my case, it was not feasible (for business, not technology) reasons) to prevent people from creating libraries. The technology allows it of course, as others pointed out here. However, in the environment I was in, there were programmers supporting clients all over the world at all hours of the day and night, and the sheer volume of the libraries they created would have drowned me in paperwork if they had applied to me for every library they created - and the application for new library would have slowed them down considerably. In addition, there were lots of application programs that created temporary and permanent libraries on the various systems. If you want to allow users to create new libraries whenever they want, but want to be aware of the new ones, you could create a custom command (as outlined by the others), and have the command prompt for the information you want the user to provide you. Then have the command processing program send you a message or create a record in a file for you. If you are the person responsible for disk monitoring, you might consider asking whether the library is temporary or permanent. Then, if temporary, ask for an estimated end date. This gives you a tickler for following up with them. In addition, I would ask for information that helps you identify the long term custodian of the library. For example, the library might be created by Debbie, but Debbie could transfer to a different project soon after and not be the appropriate contact. So, ask for something to help you identify over the long term - e.g. Name of Client, Application, or Project (depends on how your work teams are organized). Also, if you're going with a custom command, force the entry of the Text Description. If your company doesn't already have naming standards for library names, this might be a good time to create some. It will allow libraries to be more easily identified and grouped for reporting. If you are going to start some naming standards, start with drafts and review them carefully with the programmers/project leaders. They will have application reasons for wanting the name to include/exclude certain conventions, and it will be well worth your while to invest the time in making sure the standard will be workable. Regards, Debbie Gallagher