|
Hi Steve,
This is my second reply. The first got cancelled due to the link being lost
(yes, interactive replies really get on your nerves sometimes...).
OK. You're correct, for all kinds of (valid) reasons the documentation doesn't
contain information about maintaining element types.
> %OA-I-LASTLINE, Error occured in check status action routine
In V2.* there was a CM$ETYPES data set which contained 5 records (5 element
types supported) and a number of basic routines to be called. In V3.0,
CM$ETYPES is the engine of CM. Without it CM is helpless.
I'm just wondering if the EXE & CLD element types were defined in V2.*. The
V3.0 installation procedure doesn't convert CM$ETYPES as the contents changed
too much (4 screens of new fields).
If you want to have a go, please read on.
In your specific case, it seems you deal with .EXE files which should be
deleted from CM. Ask a few questions:
1) Should the Live version of the .EXE be deleted?
We assume we're talking about 'STANDARD' element types.
Have a look at the Standard FGN element type. Always look for a template which
has most in common of what you want to do. E.g. the standard SCP element type
(and routines) could serve as a template for a system wide UDP element type.
The way the Foreign Element type works is:
1) Create, you're asked for a template name. The file is copied to
OA$SITE_DEV_<appl area>, and the Live Location is set to where the template
came from. If you move the element to Live then that will be the Live
location.
2) Edit, not allowed
3) Delete, you will delete the element from the Development area. The Live
version will not be deleted.
etc.
Check if the procedures need to change in order to meet your requirements. Then
create your Standard EXE element type, use 'STANDARD FGN' as the template, and
make the necessary changes to the record. E.g., the first page could look like:
Standard and Exception Element Action Routines
Name: STANDARD
Type: EXE
Area:
Extension: EXE
Description: Image element
Development Library:
Template:
Mandatory GOLDA: Y Element Type Number: 0200
Function call: RUN
Conflicting Types: ,
Supplementary options: CM$OPTIONS$EXE
Update live location: N Delete develop version when moved to live: N
Create
Name Validation: DO CM_NAME_VALIDATE_FILE
GOLDA: DO CM_FILE_TEMPLATE
Prepare Create: DO CM_PRE_CREATE_FGN
Create: GET #CM_STATUS = 1
Post Create: DO CM_POST_EDIT_TEXT
The 'Mandatory GOLDA' indicate that when creating an EXE element, you're always
asked for a template if set to 'Y'.
The 'Element Type Number' is automatically assigned. 1-199 is reserved by
Digital, you'll start with 200. This field can only be changed interactively
(PF1 7).
The 'Function call' is used by CART to figure out how an EXE element is called
from within other procedures/forms.
The 'Conflicting types' indicate which elements types conflict with EXE. E.g.,
OABLI, OAB32, OAMAR, OASDF, OASCT, SDF and SCT conflict as their final files
will be .OBJ, which is the same for all element types. Another example: BLP and
BLPW conflict because they might appear in the same Live location, and the TXL
compiler might not like that. In your case I don't think a conflict arises.
Supplementary options is a form (no .TYPE) which contains the Named data
associated to options like Read, Print, Send, GOLD GET, Differences. It advised
to create a specific one for every element type. Create your own CM$OPTIONS$EXE
with CM$OPTIONS$FGN as template, as you're pretty safe in assuming that
processing will be the same for both element types.
Use 'Update Live locations' to indicate if a Programmer can update the Live
Location (option UED). As indicated for the FGN element type, this is set to
'N' because the Live location is decided according to the location of the
template. You might decide different afcourse for the EXE element type.
The 'Prepare Create' I left the same as the procedure CM_PRE_CREATE_FGN.SCP
does all what is needed for the EXE type also, if you decide that that's the
way it should work. If not, then create your own version of
CM_PRE_CREATE_EXE.SCP with CM_PRE_CREATE_FGN as the template, make your
modifications and change the value in the CM$ETYPES field.
NB. It is advised to put element, created for element types, in the OA
application.
The important procedures to look at are probably:
CM_*_FGN.SCP
CM_PUT_FGN.SCP
CM_GET_FGN.SCP
CM_DELETE_FGN.SCP
Once you've finished the element type record, CM will add the necessary menu
options to the CM$OPTIONS$TYPE data set (using the options of the template
element type you used) options needed to make the options Read, Print, Send,
GOLD GET, Differences, Template, etc. initially work. You might need to check
if the options are OK (also the option description).
The other application areas need know about the new element type, so use option
IA 'Initialize all applications for new element type' to initialize the element
type.
Also consider a number of Live (Base) locations for the element type, which
should be added via the options CM AM MAL.
For the CLD element type, this is pretty much like an ordinary TEXT file
(Standard element type ASCII), with one difference that when moved to the Live
area you probably want it replaced in DCLTABLES.EXE (maybe even cluster wide).
In that case, use the ASCII element as a template, and review the following
procedures (and probably create your own ones):
CM_SM_DELETE_TEXT.SCP
CM_SM_MOVE_LIVE_TEXT.SCP
CM_SM_REMOVE_LIVE_TEXT.SCP
CM_SM_MOVE_BASE_TEXT.SCP
Also, a Live location needs to be defined.
This is a start. Hope it helps,
Simon
|