|
Hi, Stuart. Maybe, I'm not understanding your question, but, if you are going to create separate data libraries per JBA company, wouldn't you just build the LFs in the same library and point them at the corresponding PFs. E.g., if I have 3 company specific libraries - call them JBADATA01 through JBADATA03 - all I do is create CUSNAMES, CUSALPH, etc., over SLP05 in each of the respective libraries. Off the top of my head (a dangerous place, if the coffee hasn't filtered through!), if you are starting out with a consolidated data library, I'd do the following: (A) On a dedicated system, create a save of the original consolidated data library. (B) Rename the original data library to JBADATA01 (continuing from the above example), then restore the backup made in step A. I now have my original consolidated data library and a copy called JBADATA01. All the LFs in each library point at PFs in the same library. (C) Run a CL program to clear every PF member in JBADATA01. (D) Save JBADATA01, rename JBADATA01 to JBADATA02, restore JBADATA01 from backup. (E) Rename JBADATA01 to JBADATA03, restore JBADATA01 from backup. I now have 3 new, company specific data libraries, with no data in the PFs thereof. (F) Run a program(s) to transfer company data from a PF in your original consolidated data library to the same PF in the corresponding company specific data library. (Unless you have a lot of spare disk, remember to delete records in the original PF, as you copy them to the new PF). You still have the challenge of how to get the JBA application to understand your new library structure, so that users get data from the appropriate company, as they work with the system. I suppose one possibility is to create a sign on program that adds the appropriate company specific data library to the interactive job's system library list prior to invoking the AM3 command to access JBA. Obviously, this sign on program would have to be sophisticated enough to figure out which company specific data library corresponded to the user. You wouldn't even have to mess around with task library lists, using this approach. As always, should you or any of your I.S. staff be caught or killed during this exercise, yours truly will disavow any knowledge of your actions. Therefore, remember to plan and test for success!
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.