T.R | Title | User | Personal Name | Date | Lines |
---|
1211.1 | Key lengths in libraries: 39 / 31 | CESARE::EIJS | All in 1 Piece | Tue Aug 11 1992 09:53 | 38 |
|
Derek,
I wonder if you really mean 'move HELP libraries to Live' instead of
'move HELP elements to Live'?
What happens:
When an HLP element is created, the element will be stored in
OA$SITE_DEV_<application area>:DEVELOP.HLB (unformatted) and in
OA$SITE_DEV_<application area>:FORMATTED_DEVELOP.HLB (formatted) just
like an FRM element is stored in DEVELOP.FLB. The key lengths for both
libraries are equal to the key lengths used for
HLPSOURCE.HLB (unformatted) and OAHELP.HLB (formatted).
Key length unformatted = 39, formatted = 31.
If you're not using the Live OA HELP libraries (SITEHLPSOURCE and
OAHELP (it's explained before why it's recommended to use them)) then
your own help libraries should accept these key lengths.
If your library accepts a keyl length of 15, and it contains HELP
modules already, I think you can convert them via:
$ LIBR/CREATE/HELP/KEYSIZE:39 <new lib> <old lib>.HLB
or:
$ LIBR/CREATE/HELP/KEYSIZE:31 <new lib> <old lib>.HLB
(A library (in this case HELP) is created by default with a key length
of 15)
HTH,
Simon
|
1211.2 | CM seems to have done it | KAOFS::D_STREET | | Wed Aug 12 1992 20:32 | 21 |
| The client says he used CM to do all his work, and the following is the
"problem" that he had with it.
While under development, the help was in:
KP1$SITE_DEV_ENGLISH:DEVELOP.HLB
KP1$SITE_DEV_ENGLISH:FORMATTED_DEVELOP.HLB
When he moved them live they ended up in:
KP1$SITE_LIB_ENGLISH:OAHELP.HLB
KP1$SITE_LIB_ENGLISH:SITE_HLP_SOURCE.HLB
These files are the one that had the keylength of 15. As they were
created via CM, the client had no oppertunity to set them up
incorrectly. He also observed the same problem when he moved them to
the BASE area. (KP1$LIB_ENGLISH:)
He has done the compress, and has the system working, but would like
to know if this is a problem he created for himself, or of it is one
that ALL-IN-1 should address.
Derek Street.
|
1211.5 | Disagree, it cannot be CM (this time) | CESARE::EIJS | All in 1 Piece | Wed Aug 12 1992 23:29 | 44 |
|
Hi Derek,
This might not be the most enthousiastic answer, but something is
really strange...
1) KP1$SITE_DEV_ENGLISH/KP1$SITE_DEV_SHARE logicals. CM expects all
development logicals to start with OA$SITE_DEV_mumble, else CM won't
work. Now I don't expect Keypak to have re-written CM, so I presume
these logicals are OA$SITE_DEV_mumble.
2) CM NEVER creates Live (and Base) Libraries. CM creates DEVELOP.HLB
and FORMATTED_DEVELOP.HLB in both the Development area and Receive
area when an application area is created via CM. The Live (and Base)
HELP libraries MUST exist before CM allows them to be valid Live
(Base) locations.
My guess is that when this (guessed) product was installed, the
installation procedure took care of creating:
Development area
Receive area
Live (and Base) locations
Live (and Base) Form and HELP libraries
Entries in CM$AUTH$LOCATIONS
and this way all checks normally performed by CM when creating an
application area weren't performed.
SO I think I can safely state that CM isn't to blame here. I'm afraid
we need to have a closer look at what happened either during or after
the installation of Keypak. Has anyone else installed Keypak? If so,
can you check what the keyzsize is of DEVELOP.HLB,
FORMATTED_DEVELOP.HLB, OAHELP.HLB and SITE_HLP_SOURCE.HLB?
Ciao,
Simon
PS If it's Keypak indeed, Stuart D. asked for info about CM+...
|
1211.6 | a "PA" seems to say it's possible | KAOFS::D_STREET | | Thu Aug 13 1992 18:44 | 145 |
| Hello
I have created a new application via CM MA C, which has the name "DS".
I then created an application area via CA, which has a name of
"DS_XXX". Then I do a PA to print the details about the application. It
looks to me like a "DS" area is created, not under "OA". I get the
following information:
Application Information
Application: DS
Description: test of creation of new app area
Root Directory: DISK$USER_3:[D_STREET.DS.BASE]
Site Root Directory: DISK$USER_3:[D_STREET.DS.SITE]
Date Created: 13-Aug-1992
Date Modified: 13-Aug-1992
Language:
Version:
Initial Application Maintainer: MANAGER
Total No. Of Application Areas: 1
Original Engineering Flag: 1
Storage Status Flag: 0
Application Area Information
Application: DS
Area code: XXX
Area: DS_XXX Area status: Open
Language: Priority: 50
First Installation: 13-Aug-1992 last upgrade: 13-Aug-1992
Version:
Description: test of area creation
Root: DISK$USER_3:[D_STREET.DS.BASE]
Site Root: DISK$USER_3:[D_STREET.DS.SITE]
Startup:
Message file:
Min. version: Max. version:
Flags: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
Application Area Information (Continued)
Authorized Live Locations for Application Area DS_XXX
Element type: A1MSG
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for A1MSG elements
Open: Y
Element type: ASCII
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for ASCII elements
Open: Y
Element type: BLP
Location: DS$SITE_BLP_DS_XXX:
Description: Default TXL directory for BLP elements
Open: Y
Element type: BLPW
Location: DS$SITE_BLP_DS_XXX:
Description: Default TXL directory for BLPW elements
Open: Y
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for BLPW elements
Open: Y
Element type: CMU
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for CMU elements
Open: Y
Application Area Information (Continued)
Element type: COM
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for COM elements
Open: Y
Element type: DO
Location: DS$SITE_DO_DS_XXX:
Description: Default TXL directory for DO elements
Open: Y
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for DO elements
Open: Y
Element type: ESO
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for ESO elements
Open: Y
Element type: FDL
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for FDL elements
Open: Y
Element type: FGN
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for FGN elements
Open: Y
Application Area Information (Continued)
Element type: FRM
Location: DS$SITE_LIB_DS_XXX:SITEXXX.FLB
Description: Default form library for application DS
Open: Y
Element type: LSO
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for LSO elements
Open: Y
Element type: OAB32
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for OAB32 elements
Open: Y
Element type: OABLI
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for OABLI elements
Open: Y
Element type: OAMAR
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for OAMAR elements
Open: Y
Element type: OASCT
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for OASCT elements
Open: Y
Application Area Information (Continued)
Element type: OASDF
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for OASDF elements
Open: Y
Element type: PRA
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for PRA elements
Open: Y
Element type: PRC
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for PRC elements
Open: Y
Element type: SCP
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for SCP elements
Open: Y
Location: DS$SITE_SCP_DS_XXX:
Description: Default TXL directory for SCP elements
Open: Y
Element type: SCT
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for SCT elements
Open: Y
Application Area Information (Continued)
Element type: SDF
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for SDF elements
Open: Y
Element type: WPL
Location: DS$SITE_LIB_DS_XXX:
Description: Default directory for WPL elements
Open: Y
|
1211.7 | Only OA$SITE_DEV_mumble -> 'OA$' | CESARE::EIJS | All in 1 Piece | Fri Aug 14 1992 09:43 | 16 |
|
Hi Derek,
> Element type: ASCII
> Location: DS$SITE_LIB_DS_XXX:
> Description: Default directory for ASCII elements
> Open: Y
I'm sorry if .5 caused some confusion. I was only referring to
OA$SITE_DEV_mumble logicals which should start with 'OA$'. The
(automatically generated) Live (and Base) logicals can start with
something else.
Ciao,
Simon
|