|
A few comments on the ASP questions: 1). The number for User ASPs ranged from 2 to 16 prior to V5R1. In V5R1 they go all the way to 32. This completely omits the issues regarding Independent ASPs, (those numbers go up to 99) which only hold IFS objects in V5R1, but based on an IBM SOD will include library objects and DLOs in a future release. 2). There are two kind of User ASPs, "Old ASPs" and "New ASPs". As you mentioned in your post, a library is assigned into an ASP, although the User ASPs have the option of overflowing into the system ASP, which compromise the integrity of the ASP until it is fixed. This was the ASP implementation as introduced in V1R3. Prior to V1R3, User ASP libraries all existed in ASP #1, but a User ASP was defined as such the first object created in that ASP. Then, only journals, journal receivers and save files could exist in a User ASP, and if the first object created in that ASP claimed it, then the ASP was used. Today both types of ASP coexist, and must be either the "Old" type or the "New" type. This causes it to be very difficult to code for these different type of ASPs, and I am unaware of any easy way to determine if a User ASP is "Old" or "New". (This might be possible via API, but I have not coded to it.) Al - on the way from Charlotte back to New York Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com "Steve Richter" <srichter@AutoCoder To: <midrange-l@midrange.com> .com> cc: Sent by: Subject: Re: Question(s) on ASP's midrange-l-admin@mi drange.com 04/01/02 11:39 AM Please respond to midrange-l I had a transitioning 720 to work with last week ... there can be from 1 to 16 ASPs on the system. You use DST to physically assign disk drives to each ASP. ASPs from 2 to 16 can be compressed at the drive hardware level. Libraries are assigned to an ASP. All the objects in the library then reside in the ASP. Use SAVLIB and RSTLIB to move a lib from one ASP to another. Dont overflow an ASP. When I was restoring to a compressed ASP, the ASP overflowed and the 720 croaked a slow death. That was the end of my experiment. The ASP concept is excellent. - mirror the drives that your production data is on, dont mirror the online save files. - compress seldom used libraries, dont compress others with the potential of: - physically seperate one appl from another. - no disk contention between the applications. - to load or unload an application from the system, just pull or insert the drive(s) ?? But sadly, IBM has not completed the circle - reconfiging your ASPs is time consuming. - ASP overflow is a hassle and from my brief experiment, a system killer. Object level asp assignment and real time asp config are needed. -This would enable the system to transition the system one object at a time after a real time ASP config change. -Also, ASP overflow could be better handled, as the overflowing object would simply be moved to an ASP that has room. Steve Richter ( expression space left intentionally blank ) _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
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.