HP 3000 Manuals HP 3000 Manuals
General Programming Hints and Tips
Passwords
Programs that use the Intrinsics need to handle passwords. Care must be
taken that these passwords are not accessible to unauthorized users.
Ideally they should not be stored by your programs, however, this may be
unavoidable. If you have to store passwords, your files must be stored
in groups with public eXecute access and not Read access. It is a great
advantage if the passwords are maintained in a way which allows them to
be changed regularly without having to recompile the code.
The Transaction File
The Transaction File is used to pass information back to the calling
process. The calling process must therefore open the Transaction File in
a way which allows it to be written to by the Intrinsics Driver. It must
be opened with READ/WRITE, SHARE and MULTI access. The calling process
need not close the file before supplying it to an Intrinsic, however, it
will need to reset the file pointer if, for example, it needs to
reprocess the file. The fourth element of the status array (returned by
Intrinsics that require Transaction Files as input) points to the first
of any transaction records in error and so can be used to reset the
pointer.
Handling Erroneous Transaction Files
If you submit a Transaction File with errors in it these errors are
reported in the status parameter which is a 12 element array. The first
element indicates the Transaction File is invalid. The other elements
are used to give more information, such as the first record in error and
how many errors there are in the file.
Transaction records containing errors have their transaction result field
set to provide further error details. Therefore, instead of scanning the
whole file you can go to the first record as shown in the status
parameter and scan the file from there until the number of errors
reported have been found. These transaction result fields are only set
if an error occurs in that transaction record, this saves performance
overhead by not setting status to 0 if the transaction type is correct.
This means that if you don't fill files with zeros before you use them
and there is more than one error reported, you may not be able to tell
which errors were reported this time around.
Rules Used to Validate Names and Addresses Supplied in Distribution Lists
If you supply a Distribution List to HPDGateSend which contains a foreign
alias defined on the gateway database, then the name and node given by
the alias will be used, irrespective of any name and node supplied in the
Transaction File.
If an alias is not supplied, or the one supplied is not defined on the
gateway database, HPDGateSend validates supplied names and nodes in the
same way as HPDUserSend. [REV BEG]Note that HPDGateSend and HPDUserSend
do not validate that usernames that are referenced in Distribution Lists
are configured in the database unless the nodename is missing. [REV END]
This validation is described below:
* If both the name and node are missing, the message is rejected.
* If the name contains invalid characters and the sp_accept_fail
Session Profile record is set to accept badly formed names, the
message will still be sent, but this particular name is ignored.
If the sp_accept_fail record is set to reject badly formed names,
the message will not be sent to anyone on the Distribution List.
* If the node contains invalid characters and the sp_accept_fail
Session Profile record is set to accept badly formed nodes, the
message will still be sent, but this particular name and node is
ignored. If the sp_accept_fail record is set to reject badly
formed nodes, the message will not be sent to anyone on the
Distribution List.
* If the node is valid but not configured on the node database, then
if the sp_accept_fail Session Profile record is set to accept
non-configured nodes, the message will still be sent but this
particular name is ignored. If the sp_accept_fail record is set
to reject non-configured nodes, the message will not be sent to
anyone on the Distribution List.
* If no node is supplied and the message is marked as private, the
message is not sent to anyone on the Distribution List. If the
message is not marked as private, the Intrinsic will look for the
name supplied in the global user dataset. If a unique name match
exists, the message is sent. If the name does not exist in the
dataset, or is not unique, then if the sp_accept_fail Session
Profile record is set to accept non-configured or badly formed
names, the message will still be sent, but this particular name is
ignored. If the sp_accept_fail Session Profile record is set to
reject non-configured or badly formed names, the message will not
be sent to anyone on the Distribution List.