| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2611.1 | you must have a fullname identifier | TOOK::NELSON | | Mon Mar 23 1992 13:24 | 71 |
| RE: .0
>I am currently working with DECMCC V1.1 and appendix E tells me that I can use
>a simplename for a dns_ident = primary_name.
>The V1.2 appendix C states that a fullname is required.
>Can somebody clarify this ?
The SRM has always required the fullname identifier for a global entity.
It was not enforced by the DECmcc product until V1.2. For example
purposes and as a short cut, we often left this fullname identifier out
of the class definition. For V1.2 you MUST have an identifier of
datatype fullname (marked as DNS_IDENT=PRIMARY_NAME) for your global
entity class.
>Suppose I would change this ms and use a fullname as primary_name, and a
>simplename as an alternate for example, how does a directive like show uaf
>.uaf.demoor (for example) all char process the string .uaf.demoor.
>Does it use dns routines to go and find the fullname in dns, or should this name
>be in the local cache of which appendix C speaks?
I am not sure who `it' is in your question. However, if you were to say
SHOW UAF .uaf.demoor ALL CHAR
and you had a fullname identifier defined for class UAF, then the PM
will encode the string ".uaf.demoor" as datatype fullname. Your AM then
has the responsibility to convert the fullname to an identifier useful
to the SYS$UAF routines. An example of converting a fullname to a
string and pulling off the `local' name is in the Sample AM code for
V1.2. Your other option, given the fullname, is to get the alternate
name from the instance database using mcc_dns_get_identifiers (assuming
that the entity is registered). If it is not registered, then it
shouldn't have a valid fullname identifier until you register it.
>About the register command : shouldn't the cache appendix C mentions be a
>global section in stead of some local static storage, so multiple instances of
>decmcc on the same machine could use it at the same time ?
The cache is meant to be a short term storage for use just during the
registration process. We would assume that the register takes place
inside the context of just one instance of an AM. However, if you want
to take into account more complex situations, you are free to put your
cache anywhere you want. The cache is used to keep the association
between the registered name and any other information entered as
parameters to the REGISTER operation. This association must be kept by
the AM only so that the SHOW IDENTIFIERS returns the entire identifier
partition and so that the AM can put any other information into a more
permanent storage. The cache is not meant to be long term storage.
>Suppose I do not use fullname for the primary name and I construct my cache
>as simpelname, pointer to fullname in the register directive when a user
>entered for example register uaf .uaf.lala name=lala
You must use the fullname identifier as the DNS_IDENT=PRIMARY_NAME.
> (I presume I created a
>.uaf directory in DNS ). Is this the right way to do so.
>Does the register fm check the existence of the .uaf dir ?
You must create the .uaf directory in DNS. If the directory does not
exist, the REGISTER operation will fail.
>I hope these questions are not too confusing.
>Regards,
>Kurt.
Hope this helps,
...kjn
|
| 2611.2 | Thanks. | PLAYER::DEMOOR | | Tue Mar 24 1992 03:19 | 5 |
| Thanks KJ, this is exactly what I need to proceed !
Regards,
Kurt
|
| 2611.3 | Additional questions | BIS1::COLLEYE | | Wed Mar 25 1992 11:01 | 68 |
| Hello,
In addition to Kurt's question:
1 - We have followed your instructions. ie:
i - the register directive (in the service code) stores in a cache
the fullname and the alternate name.
ii - the show identifier directive, retrives form that cache
the fulname and the alternate name and returns
(mcc_ilv_put_cons) the fullname and the alternate name
Howver, it appears from the following log in appendix that the registration
does not work (%MCC-E-NOENTITY, no corresponding entity instance exists)
This error message is not generated by our AM, but would be generated
by the information manager, dictionary routines.
Any idea why ?
2 - The Management Module Programming Manual (V1.1) states in appendix E,
p E-9, fig E-4, that the AM should issue a DNS_WRITE_ATTRIBUTES.
Is it the mcc_dns_write_attr_data routine ?
In the affirmative, what should be written (what is the attribute code ?) ?
Currently, we have not iserted any instruction to issue
a DNS_WRITE_ATTRIBUTES; could this be the cause of the first related issue ?
Regards,
Maurice.
================== A P P E N D I X ==============
TPLAB> mana/enter/nodebug
DECmcc (V1.1.0)
MCC> register uaf .uaf.colleye altname=Colleye
%MCC-S-NORMAL, normal successful completion
Beginning MCC_UAF_LOG
%MCC-E-REVECTCONFLICT, revectoring conflict
-SYSTEM-F-DEBUG, command interpreter debugger signal at PC=00123757, PSL=03C00000
Beginning UAF_REGISTER
%MCC-E-REVECTCONFLICT, revectoring conflict
-SYSTEM-F-DEBUG, command interpreter debugger signal at PC=00123757, PSL=03C00000
Beginning uaf_validate_args
uaf_validate_args completed successfully
UAF_REGISTER completed successfully
Beginning UAF_SHOW_IDENT
%MCC-E-REVECTCONFLICT, revectoring conflict
-SYSTEM-F-DEBUG, command interpreter debugger signal at PC=00123757, PSL=03C00000
Beginning uaf_validate_args
uaf_validate_args completed successfully
UAF_SHOW_IDENT completed successfully
uaf SDE:.uaf.colleye
AT 25-MAR-1992 16:44:10
The requested operation cannot be completed
MCC Unhandled Service Reply = UAF show successful
Username = Colleye
%MCC-E-NOENTITY, no corresponding entity instance exists
%MCC-E-NOENTITY, no corresponding entity instance exists
MCC> Exit
|
| 2611.4 | Probably ILV encoding error | MOLAR::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Wed Mar 25 1992 12:14 | 10 |
| >> %MCC-E-NOENTITY, no corresponding entity instance exists
This could be an ILV encoding error. When you encode the data in Out-P
are you setting the Descriptor Id Field?
Set the FCL Log bit to display the Out-P ILV encoding:
$ define mcc_fcl_pm_log 8
/keith
|
| 2611.5 | UAF Registration issue (Cont) | BRSIS2::COLLEYE | | Thu Mar 26 1992 11:33 | 251 |
| Keith,
Thank very much you for your advise.
I have checked the ILV and it seems now OK as it appears
in the following appendix.
However, the registration still does not work:
"The requested operation cannot be completed"... and nothing is stored
in DNS.
Any idea ?
Should the SHOW IDENT set up an output entity ?
In advance thank you.
Regards,
Maurice.
Additional info:
----------------
The .uaf & .MCC_uaf_BackTranslations DNS directories are
created.
Note also, in the appendix , that the default Namespeace (SDE:) is properly
added.
The REGISTER directive properly caches the identifiers:
- the full namespace (input as entity instance in the REGISTER
directive)
- the alternate identifier (input parameter altname in the
REGISTER directive).
The SHOW directive properly retrieve the identifiers form
the cach and output (ilv encode output parameter):
- the alternate identifier (Username output parameter)
- the full namespace (Userid output parameter)
In the MSL:
- Username & Userid are two identifiers of the UAF class
================= SAMPLE MSL ===========================================
GLOBAL ENTITY uaf = 33 :
IDENTIFIER = ( Username ,UserId ),
SYMBOL = CLASS_UAF,
(* attribute partition with attribute definitions *)
IDENTIFIER ATTRIBUTES
ATTRIBUTE Username = 20 : SimpleName
DNS_IDENT = ALTERNATE_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = ATTR_Uname
END ATTRIBUTE Username;
ATTRIBUTE UserId = 21 : FullName
DNS_IDENT = PRIMARY_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = ATTR_Uid
END ATTRIBUTE UserId;
END ATTRIBUTES;
========================================================================
- Altname is the requested argument of the REGISTER directive
================= SAMPLE MSL ===========================================
DIRECTIVE Register = 29 :
DIRECTIVE-TYPE = ACTION,
DISPLAY = TRUE,
SYMBOL = REGISTRATION_REGISTER,
CATEGORIES = (CONFIGURATION),
REQUEST
ARGUMENT altname = 01 : SimpleName
SYMBOL = ATTR_altname,
ECHO = TRUE,
DISPLAY = TRUE,
REQUIRED = TRUE
END ARGUMENT altname ;
END REQUEST;
====================================================================
==================== A P P E N D I X ===========================================
TPLAB> mana/enter/deb
VMS Debugger Version T5.6DS-001
%DEBUG-I-NOGLOBALS, some or all global symbols not accessible
%DEBUG-I-DYNMODSET, setting module MCC_MAIN
DBG> go
DECmcc (V1.1.0)
MCC> register uaf .uaf.colleye altname=Colleye
*****************************************************
* FCL PM Arguments before call_function: *
*****************************************************
VERB code: 29
PARTITION code: 10
AES dump of ENTITY IN:
depth=1 class code= 33 instance = �
ILV dump of IN_P:
[ 0 ] (
[ 1 ] 01 07 43 6f 6c 6c 65 79 65
)
ILV dump of IN_Q: in_q is NULL
TIME SPEC is: 0, NOW
%DEBUG-I-DYNIMGSET, setting image MCC_UAF
%DEBUG-I-DYNMODSET, setting module UAF_INIT
%MCC-S-NORMAL, normal successful completion
Beginning MCC_UAF_LOG
DBG> go
Beginning UAF_REGISTER
%DEBUG-I-DYNMODSET, setting module UAF_SRVC
DBG> go
Beginning uaf_validate_args
uaf_validate_args completed successfully
UAF_REGISTER completed successfully
Beginning UAF_SHOW_IDENT
DBG> go
Beginning uaf_validate_args
uaf_validate_args completed successfully
UAF_SHOW_IDENT completed successfully
**********************************************
FCL PM Arguments on return from call_function:
CVR returned:
%MCC-S-COMMON_EXCEPTIO, success with common exception reply
ILV dump of OUT_P:
[ 2 ] (
[ 16 ] (
[ 1 ] 03 26 80 49
[ 2 ] 01
[ 3 ] (
[ 0 ] (
[ 1 ] 01
[ 2 ] 21 -- !
[ 3 ] 15
[ 4 ] 05
[ 5 ] aa 00 04 00 74 c0 b0 b0 ff 3d 4f 3b 95 00 10 00 01 03 75 61
66 01 07 63 6f 6c 6c 65 79 65 00 00
)
)
[ 4 ] (
[ 10 ] (
[ 100 ] (
[ 20 ] (
[ 1 ] 04
[ 2 ] 01 07 43 6f 6c 6c 65 79 65
[ 3 ] 00
)
[ 21 ] (
[ 1 ] 05
[ 2 ] aa 00 04 00 74 c0 b0 b0 ff 3d 4f 3b 95 00 10 00 01 03 75 61
66 01 07 63 6f 6c 6c 65 79 65 00 00
[ 3 ] 00
)
)
)
)
)
)
AES dump of ENTITY OUT:
depth=1 class code= 33 instance = �
uaf SDE:.uaf.colleye
AT 26-MAR-1992 17:02:35
The requested operation cannot be completed
MCC Unhandled Service Reply = UAF show successful
Username = Colleye
UserId = SDE:.uaf.colleye
MCC>
MCC> show uaf .uaf.colleye all ident
*****************************************************
* FCL PM Arguments before call_function: *
*****************************************************
VERB code: 1
PARTITION code: 1
AES dump of ENTITY IN:
depth=1 class code= 33 instance = �
ILV dump of IN_P: in_p is NULL
ILV dump of IN_Q: in_q is NULL
TIME SPEC is: 0, NOW
Beginning UAF_SHOW_IDENT
DBG> go
Beginning uaf_validate_args
uaf_validate_args completed successfully
UAF_SHOW_IDENT completed successfully
**********************************************
FCL PM Arguments on return from call_function:
CVR returned:
%MCC-S-RESPONSE, success with response reply
ILV dump of OUT_P:
[ 10 ] (
[ 100 ] (
[ 20 ] (
[ 1 ] 04
[ 2 ] 01 07 43 6f 6c 6c 65 79 65
[ 3 ] 00
)
[ 21 ] (
[ 1 ] 05
[ 2 ] aa 00 04 00 74 c0 b0 b0 ff 3d 4f 3b 95 00 10 00 01 03 75 61
66 01 07 63 6f 6c 6c 65 79 65 00 00
[ 3 ] 00
)
)
)
AES dump of ENTITY OUT:
depth=1 class code= 33 instance = �
uaf SDE:.uaf.colleye
AT 26-MAR-1992 17:07:22 Identifiers
UAF show successful
Username = Colleye
UserId = SDE:.uaf.colleye
MCC>
|
| 2611.6 | bug in UAF management spec is your problem | KAJUN::NELSON | | Thu Mar 26 1992 13:45 | 24 |
| You are encountering a bug in the UAF management specification that was
not a problem in V1.1, but is enforced in V1.2. We have since updated
the UAF management specification.
The response codes in the V1.1 version of the UAF management
specification are not standard.
The SHOW IDENT works from the FCL because the FCL is totally dictionary
driven, so if the wrong codes get into the dictionary everything works,
but sort of accidently.
When the REGISTRATION FM calls your SHOW IDENT entry point, it expects and
checks for a response code of MCC_K_SHOW_SUCCESS and expects that code
to be equal to 1. You can see from the out_p on your SHOW IDENT and
from your UAF management specification that the symbol
(MCC_K_)SHOW_SUCCESS has been set to 10, not 1.
For each of the common directives, defined in Chapter 15 of the SRM,
DECmcc expects the (MCC_K_)<verb>_SUCCESS response code to be defined as 1.
Try changing your UAF management spec and rebuilding the AM. This
should fix your registration problem.
...kjn
|
| 2611.7 | MSL corrected but still does not work | BIS1::COLLEYE | | Fri Mar 27 1992 03:50 | 158 |
| Keith,
Thank very much you for your advise.
I changed the MSL so that all (MCC_K_)<verb>_SUCCESS are equal to 1.
I also copied back the original files from the training (MCC_DEFINITION.DAT,
MCC_DICTIONARY.DAT, MCC_DISPATCH_TABLE.DAT, MCC_MIR_ATTRIBUTE.DAT,
MCC_MIR_DIRECTORY.DAT) and I rebuilt the whole UAF.
Apart what is explained above, what I state in .5 is not changed.
This time I have another error message on the regiter (a DNS message).
After a trial to register the SHOW_IDENT still works.
Do you have an idea of what could be wrong ?
Thank you,
Regards,
Maurice.
TPLAB> mana/enter/deb
VMS Debugger Version T5.6DS-001
%DEBUG-I-NOGLOBALS, some or all global symbols not accessible
%DEBUG-I-DYNMODSET, setting module MCC_MAIN
DBG> go
DECmcc (V1.1.0)
MCC> register uaf .uaf.colleye altname=Colleye
*****************************************************
* FCL PM Arguments before call_function: *
*****************************************************
VERB code: 29
PARTITION code: 10
AES dump of ENTITY IN:
depth=1 class code= 33 instance = �
ILV dump of IN_P:
[ 0 ] (
[ 1 ] 01 07 43 6f 6c 6c 65 79 65
)
ILV dump of IN_Q: in_q is NULL
TIME SPEC is: 0, NOW
%DEBUG-I-DYNIMGSET, setting image MCC_UAF
%DEBUG-I-DYNMODSET, setting module UAF_INIT
%MCC-S-NORMAL, normal successful completion
Beginning MCC_UAF_LOG
DBG> go
Beginning UAF_REGISTER
%DEBUG-I-DYNMODSET, setting module UAF_SRVC
DBG> go
Beginning uaf_validate_args
uaf_validate_args completed successfully
UAF_REGISTER completed successfully
Beginning UAF_SHOW_IDENT
DBG> go
Beginning uaf_validate_args
uaf_validate_args completed successfully
UAF_SHOW_IDENT completed successfully
**********************************************
FCL PM Arguments on return from call_function:
CVR returned:
%MCC-S-COMMON_EXCEPTIO, success with common exception reply
ILV dump of OUT_P:
[ 2 ] (
[ 1 ] 01
[ 2 ] 01 de 80 12
)
AES dump of ENTITY OUT:
depth=1 class code= 33 instance = �
uaf SDE:.uaf.colleye
AT 27-MAR-1992 09:24:15
The requested operation cannot be completed
MCC Routine Error = %DNS-E-INVALIDNAME, Invalid name
MCC>
MCC>
MCC> show uaf .uaf.colleye all ident
*****************************************************
* FCL PM Arguments before call_function: *
*****************************************************
VERB code: 1
PARTITION code: 1
AES dump of ENTITY IN:
depth=1 class code= 33 instance = �
ILV dump of IN_P: in_p is NULL
ILV dump of IN_Q: in_q is NULL
TIME SPEC is: 0, NOW
Beginning UAF_SHOW_IDENT
DBG> go
Beginning uaf_validate_args
uaf_validate_args completed successfully
uaf_validate_args completed successfully
UAF_SHOW_IDENT completed successfully
**********************************************
FCL PM Arguments on return from call_function:
CVR returned:
%MCC-S-RESPONSE, success with response reply
ILV dump of OUT_P:
[ 1 ] (
[ 100 ] (
[ 20 ] (
[ 1 ] 04
[ 2 ] 01 07 43 6f 6c 6c 65 79 65
[ 3 ] 00
)
[ 21 ] (
[ 1 ] 05
[ 2 ] aa 00 04 00 74 c0 b0 b0 ff 3d 4f 3b 95 00 10 00 01 03 75 61
66 01 07 63 6f 6c 6c 65 79 65 00 00
[ 3 ] 00
)
)
)
AES dump of ENTITY OUT:
depth=1 class code= 33 instance = �
uaf SDE:.uaf.colleye
AT 27-MAR-1992 09:24:58 Identifiers
UAF show successful
Username = Colleye
UserId = SDE:.uaf.colleye
MCC>
|
| 2611.8 | problem narrowed down. | PLAYER::DEMOOR | | Mon Mar 30 1992 07:03 | 92 |
| We traced down the problem to the following :
When we use this msl :
GLOBAL ENTITY uaf = 33 :
IDENTIFIER = ( Username ,UserId ),
SYMBOL = CLASS_UAF,
(* attribute partition with attribute definitions *)
IDENTIFIER ATTRIBUTES
ATTRIBUTE Username = 20 : SimpleName
DNS_IDENT = ALTERNATE_NAME,***********
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = ATTR_Uname
END ATTRIBUTE Username;
ATTRIBUTE UserId = 21 : FullName
DNS_IDENT = PRIMARY_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = ATTR_Uid
END ATTRIBUTE UserId;
END ATTRIBUTES;
and issue register uaf .uaf.colleye altname=Colleye
we get
**********************************************
FCL PM Arguments on return from call_function:
CVR returned:
%MCC-S-COMMON_EXCEPTIO, success with common exception reply
ILV dump of OUT_P:
[ 2 ] (
[ 1 ] 01
[ 2 ] 01 de 80 12
)
AES dump of ENTITY OUT:
depth=1 class code= 33 instance = �
uaf SDE:.uaf.colleye
AT 27-MAR-1992 09:24:15
The requested operation cannot be completed
MCC Routine Error = %DNS-E-INVALIDNAME, Invalid name
When we use this msl :
GLOBAL ENTITY uaf = 33 :
IDENTIFIER = ( Username ,UserId ),
SYMBOL = CLASS_UAF,
(* attribute partition with attribute definitions *)
IDENTIFIER ATTRIBUTES
ATTRIBUTE Username = 20 : SimpleName
DNS_IDENT = NOT_USED,***********
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = ATTR_Uname
END ATTRIBUTE Username;
ATTRIBUTE UserId = 21 : FullName
DNS_IDENT = PRIMARY_NAME,
ACCESS = NONSETABLE,
DISPLAY = TRUE,
CATEGORIES = (CONFIGURATION),
SYMBOL = ATTR_Uid
END ATTRIBUTE UserId;
END ATTRIBUTES;
and issue the same command, all works fine, without mcc putting anything in
.mcc_uaf_backtranslation of course.
Do you see any light in this ?
Thanks,
Kurt.
|
| 2611.9 | A real answer willl have to wait awhile | KAJUN::NELSON | | Wed Apr 01 1992 14:33 | 17 |
| So sorry to be so long to reply. You are encountering a problem that I
am having a hard time reproducing because I have an unstable baselevel
on the system I was attempting to use.
Because of DECworld staging responsibilities, I have not had a chance to
continue to attempt to reproduce your problem.
There are two things you can do in the short term:
1) Wait a couple of weeks until I can track the problem down
2) Change the datatype of the alternate name to latin1string. We know
this works just fine.
I will get back to you soonest,
...kjn
|
| 2611.10 | Confusion. | PLAYER::DEMOOR | | Fri Apr 03 1992 04:34 | 27 |
| I changed the datatype of the alternate name to latin1string.
I get the following message when I try to register :
Requested operation cannot be completed
MCC Routine error %MCC_E_INVDNSIDENT, specified identifier attribute is
not valid for instance lookup.
I have a few questions :
1. Maybe DNS expects a simplename when a string of characters has to be
used for registration.
2.The cache is only used during registration, one of the replies to
this note states. If this is so we could do with a cache with only one
entry. Why does the MM manual appendix C (decmmc and dns ) speak of
several entries overwritten ect.. ?
3. Using a simplename as altname, I put it not_used in the ms.
Even then, I am able to retrieve the altname from dns with
mcc_dns_get_identifiers, so I can support the use of full names without
having something in the mcc_uaf_backtranslation directory.
Can you clear the confusion here ?
KJ , thanks for all your help and, take your time !
Kurt
|
| 2611.11 | Cache | MOLAR::BRIENEN | DECmcc LAN and SNMP Stuff... | Fri Apr 03 1992 08:48 | 16 |
| RE:
> 2.The cache is only used during registration, one of the replies to
> this note states. If this is so we could do with a cache with only one
> entry. Why does the MM manual appendix C (decmmc and dns ) speak of
> several entries overwritten ect.. ?
1. Most of the AMs (that I'm aware of) using this register caching scheme
(e.g. Bridge, Concentrator, Ethernet, Translan, FDDI) also use the
cache to improve performance.
2. Even if the cache is used strictly for REGISTER, there are potential
cases where a single entry cache could get overwritten (and there's
no way to guarantee that the SHOW ALL IDENTS immediately after the
REGISTER was related to it...
Chris
|
| 2611.12 | LOCAL_NS instead of DNS | TAVIS::ORNA | | Wed Nov 04 1992 10:11 | 5 |
| All the Q. & A. refer to a DNS namespace.
What if I use the LOCAL_NS?
Orna.
|
| 2611.13 | PLEASE answer to .12 | TAVIS::ORNA | | Mon Nov 09 1992 08:16 | 1 |
|
|
| 2611.14 | No Difference. | TOOK::MCPHERSON | pre-retinal integration | Mon Nov 09 1992 08:56 | 8 |
| > -< PLEASE answer to .12 >-
There should be NO DIFFERENCE. Caching that's taking place is completely
orthogonal re: whether or not you use DECdns or not as your instance repository.
Happy?
/doug
|
| 2611.15 | Same routine names ? | TAVIS::ORNA | | Mon Nov 09 1992 10:15 | 6 |
| The reason for my question is that the name os the routines used
in the previous replies include DNS name in it. So:do we use the
routine name?
Orna.
|
| 2611.16 | YES. Same routine names. | TOOK::MCPHERSON | pre-retinal integration | Mon Nov 09 1992 10:51 | 11 |
| > The reason for my question is that the name os the routines used
> in the previous replies include DNS name in it. So:do we use the
> routine name?
Yes. You use the *same* routines as documented in the System Reference Manual
except for those with typos. ;^)
/doug
|
| 2611.17 | as mentioned, the mcc_dns_* routines work as advertised | KAJUN::NELSON | | Thu Nov 12 1992 09:54 | 18 |
| The mcc_dns_* routines have been shelled for the local MIR option. They
do what you want them to, whether you have chosen the local MIR option
or the DNS option. The routines were shelled so that all management
modules would continue to work (no compile or link options) no matter
what instance database option was chosen by the user at installation
time. It keeps the API consistent and the task of management module
development much simpler.
We have tried as much as possible to hide the actual file
mechanisms from the management modules. You will find that the
mcc_mir_* routines and mcc_dns_* routines are actually writing to
platform dependent file systems, depending on operating system and
hardware. This is all hidden from the management module developer. The
API works as documented in the SRM (mostly %^) ). Any differences
between platforms or site-specific choices are all taken care of by the
kernel at runtime.
...kjn
|