[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

1769.0. "SUBSYSTEM Application Logicals" by GLTENG::PLATTNER () Thu Nov 12 1992 16:57

Can anybody give me some hint as how to best device/locate Applications without 
blowing up too much logical name tables:

a) handling subsystems
b) setting up application logicals and/or file search order for live appl.

First approach:
---------------
Following the terminology for standard digital applications
 - an APPLICATION 	(ALL-IN-1) consisting of various
 - SUBSYSTEMs     	(TM, CAL etc)  will be hold in appropriate
 - AREAs		(SHARE, GERMAN)


THis classification is reflected in CM$SDC.  CM$SDC$FIND allows for searches 
according to those kriteria. The application is hold in directories 
corresponding to the areas mentioned above and can be pointed to by appro-
priately defined logicals. 

We found it a good idea to group several smaller applications - subsequently 
spoken of as subsystems - into a single application. Thus avoiding to define 
to cumbersome application areas and logicals.

Here we have some difficulties to follow on the sketched lines. It is not quite
evident how to best use the various possibilities offered by CM$SITELOG to 
achieve this.

keeping the analogy between AREA and APPLICATION of CM$SDC and CM$SITELOG res-
pectively I don't know how to take advenatge of SUBSYSTEM offered in CM$SDC 
when handling CM 

CM$SDC					CM$SITELOG

AREA					AREA
APPLICATION				APPLICATION
SUBSYSTEM				?REFERENCE
		   			??SUBTYPE
		   			?UFLAG1 to 10

Is there any reserved field for this purpose.
Probably for searching, a new field must be defined in CM$INDEX$FIND ?

This would allow for a flexible managing of subsystems grouped into one 
application. E.g.: Storing, packaging the subsystems separately.

Second approach
---------------
May be the analogy between SDC and SITELOG must not be exploited to exrensively.
Perhaps  SITELOG has no tight coupling to SDC and APPLICATION may be 
interpreted as SUBSYSTEM without side effects and without offending the CM? 

The last question:
------------------
- Are there any recommendation with respect to setting up appropriate application
logicals. Do these build search lists with the OA$ areas or shall they be
setup separately.
In relation to this question we see the problem of referencing e.g. command 
procedures in applications:

	COMMAND com_proc_name
or	COMMAND appl$lib:com_proc_name

- in the first case setting up file search orders seems to be necessary when 
  the application logicals are not coupled to oa$... search lists
- in the second case some flexibility may be lost when developing/modifying the
  application. 


 Thanks in advance for help
Kind regards 
Georges

T.R	Title	User	Personal Name	Date	Lines
1769.1	Some more questions	ZHSS05::ERNI	Ursula Erni	`Fri Nov 13 1992 11:24`	17
	Hi It is really a bit confusing to put the right text into the right fields. The field REFERENCE in CM$MAF is the same as APPLICATION in CM$SITELOG and CM$SDC. REFERENCE in CM$SITELOG refers to SUBSYSTEM in CM$SDC. If I want to develop several small language dependent applications in one Application (CM$APP), I create areas like German, English, Share, ... How am I able to distinguish my small applications except that i make a WRITE CHANGE to CM$SITELOG ether in field APPLICATION or in REFERENCE (or both)? Hoping of your help Thanks, Ursi Erni
1769.2	Some explanations	CESARE::EIJS	All in 1 Piece	`Fri Nov 13 1992 18:26`	122
	Re .0) > First approach: > --------------- > Following the terminology for standard digital applications > - an APPLICATION (ALL-IN-1) consisting of various > - SUBSYSTEMs (TM, CAL etc) will be hold in appropriate > - AREAs (SHARE, GERMAN) That's the way it's supposed to work. Keeping the analogy between AREA and APPLICATION of CM$SDC and CM$SITELOG res- pectively I don't know how to take advenatge of SUBSYSTEM offered in CM$SDC when handling CM > Probably for searching, a new field must be defined in CM$INDEX$FIND ? Yes, that would be ideal (for 'Reference') > This would allow for a flexible managing of subsystems grouped into one > application. E.g.: Storing, packaging the subsystems separately. Concerning an 'Application' field in the 'Store element' Index, this has already been reported. However, to add the 'Reference'/'Subsystem' field hasn't. > Second approach > --------------- > May be the analogy between SDC and SITELOG must not be exploited to exrensively. You can, the fields (see later on) are connected as such. > The last question: > ------------------ > - Are there any recommendation with respect to setting up appropriate application > logicals. Do these build search lists with the OA$ areas or shall they be > setup separately. If you refer to the option 'Default authorized locations:' when creating Application Areas, these definitions restrict themselves to single logicals. Search Lists have to be defined yourself, say in an Application specific startup procedure (called either by e.g. CM$APP.STARTUP["<application>"], or A1V30_SITE_START.COM). > In relation to this question we see the problem of referencing e.g. command > procedures in applications:> > > COMMAND com_proc_name > or COMMAND appl$lib:com_proc_name > > - in the first case setting up file search orders seems to be necessary when > the application logicals are not coupled to oa$... search lists > - in the second case some flexibility may be lost when developing/modifying the > application. The first option would be indeed best for flexibility, but... this means that users should have the PRVXOWN field set in their PROFILe. This might not be a favourible situation, and in that case you should: - put all TXL files in TXL directies and the TXL - use 'very generic' directory specifications when calling any other procedure (as you indicated in the second option) Re .1) > It is really a bit confusing to put the right text into the right fields. > The field REFERENCE in CM$MAF is the same as APPLICATION in CM$SITELOG and > CM$SDC. REFERENCE in CM$SITELOG refers to SUBSYSTEM in CM$SDC. The field 'REFERENCE' and 'APPLICATION' go back untill V2.3. However, the way the fields were used caused some confusion: CM$SDC.SUBSYSTEM --+ CM$SDC.APPLICATION \| \| CM$SITELOG.REFERENCE \| CM$SITELOG.APPLICATION <-+ In V3.0 this has changed in: CM$SDC.APPLICATION <--> CM$SITELOG.APPLICATION CM$SDC.SUBSYSTEM <--> CM$SITELOG.REFERENCE So, in CM$SITELOG, An element might be defined as follows: Key: Element Type Application Area APPCODE: OA APPLICATION: TEST V1.5 REFERENCE: User Key: Element2 Type Application Area APPCODE: OA APPLICATION: TEST V1.5 REFERENCE: Manager In CM$SDC and element might be defined as: Key: A1 CLD SHARE APPCODE: OA APPLICATION: ALL-IN-1 SUBSYSTEM: GENERIC The field 'APPLICATION' hasn't changed in V3.0 except for the fact that CM automatically fills out the text given as description for the Application Area if the user doesn't specify another indication when creating the element (field 'Application'). (Not 'REFERENCE', but 'DESCRIPTION' is taken from CM$MAF.) > How am I able to distinguish my small applications except that i make a > WRITE CHANGE to CM$SITELOG ether in field APPLICATION or in REFERENCE (or both)? When creating the element, form CM$SITELOG$CR is shown. In there you can fill out information in the fields 'Reference' and 'Application'. Hope this helps. Ciao, Simon