Re: Hello All
- From: Paul Kimpel <paul.kimpel@xxxxxxxx>
- Date: Fri, 09 Jan 2009 08:15:47 -0800
I'll reply in context below:
On 1/5/2009 6:38 AM, dvdconroy@xxxxxxxxxxxxxx wrote:
Please let me know the following if answering them is not much of a
pain
1. When and why are more than 1 section required in DECLARATIVES
section to be used as INTERRUPT PROCEDURE. Can we assign different
interrupt procedures with different switches?
You would normally use more than one INTERRUPT PROCEDURE when you have more than one event that you want to trigger a software interrupt.
I should note that the use of software interrupts is now looked on with some disfavor. They have more overhead than other methods (the MCP has to check for the presence of the software interrupt and the happened state of the corresponding event each time the task is assigned to a processor -- with multiple interrupts this overhead is multiplied accordingly). A better approach is usually to drive the application from a central event loop that is based on a multiple-wait statement.
Personally, I only use software interrupts to fire from MYSELF.EXCEPTIONEVENT so my (batch, usually) program can easily respond to ODT HI commands.
Sorry, but I don't quite understand what you are asking in the second part of your question. You assign a relationship between events and interrupt handlers at run time with the ATTACH verb, so you could associate an event to a different interrupt (or an interrupt to a different event) based on some parametric value, such as a SWn task attribute.
2. What is the use of having different sections which have the same
names?
I assume you are talked about COBOL PROCEDURE DIVISION sections here. As far as I know, at least in currently-supported compilers, section names within the same program (source file) must be unique, so to me your question is meaningless.
3. When do we use the LOCAL-STORAGE section and how do we use it to
link to another program which is running and how can we use it to link
to a library?
In COBOL-85, the LOCAL-STORAGE section is used to provide data type information to the compiler for the formal parameters of library entry points. You define the number and sequence of parameters in an ENTRY PROCEDURE clause in the PROGRAM-LIBRARY section, and the corresponding data types in an LD entry of the LOCAL-STORAGE section. The parameters are matched up by the names you use. Here's an example:
LOCAL-STORAGE SECTION.
LD XLATE-TEMPLATE.
77 L-CCS-VER PIC S9(11) BINARY.
77 L-SOURCE-START PIC S9(11) BINARY.
77 L-DEST-START PIC S9(11) BINARY.
77 L-LENGTH PIC S9(11) BINARY.
77 L-XLATE-TYPE PIC S9(11) BINARY.
77 L-RESULT PIC S9(11) BINARY.
01 L-SOURCE-TEXT PIC X(1024).
01 L-DEST-TEXT PIC X(1024).
PROGRAM-LIBRARY SECTION.
LB MLS-LIB IMPORT
ATTRIBUTE FUNCTIONNAME IS "CENTRALSUPPORT"
LIBACCESS IS BYFUNCTION.
ENTRY PROCEDURE VSNTRANS-TEXT FOR "VSNTRANS_TEXT"
WITH XLATE-TEMPLATE
USING L-CCS-VER, L-SOURCE-TEXT, L-SOURCE-START,
L-DEST-TEXT, L-DEST-START, L-LENGTH, L-XLATE-TYPE
GIVING L-RESULT.
MCP compilers need detailed type information so that (a) they can check the types of the actual parameters that are passed to the library entry point and (b) they can build the library template data structure that the MCP uses when the library is linked. The MCP must assure that the parameter sequence of the caller is consistent with that defined for the called procedure, and the template provides that information. This is done just once, when the library is linked to the caller.
4. Are patches to a COBOL program applied only by the ADMINISTRATOR/
DBA and what is the use of $699A2 could it mean apply patch No.699A2
to the source when compiling?
I assume you are talking about source-code patches. MCP systems do not support object-code patching (and don't even think about trying it).
That said, your question doesn't make any sense to me. Source-code patches are usually applied at compilation time, or through the SYSTEM/PATCH utility. There are no special rights or restrictions on the ability to do this (other than normal file access security).
I have no idea what $699A2 could mean. Could you give an example in context of how this is being used?
In a source patch file, a "$" compiler control record that has only a sequence number on it (which must be numeric) indicates the record in the base source file with the corresponding number should be deleted, but your example is not numeric.
5 When using embedded dataset the only way to update the embedded
dataset would be by locking the paremnt record
LOCK<parent> to MODIFY
DETAIL;
Or is some other syntax also valid?
The requirement to lock master (parent) records before detail records is controlled by the LOCK TO MODIFY DETAILS option in DASDL. It is specified on the master data set. Otherwise, the master and detail records are locked using an ordinary LOCK verb -- when this option is set, you just have to lock the master record before STORE-ing any of its detail records. It is generally a good idea to lock the master before you lock any of its details, though. If LOCK TO MODIFY DETAILS is not set (the default), detail records can be updated without locking the corresponding master.
6. Is LOCK<set name> via<embedded data set name>
The only option for locking and DELETE<set name> via<embedded data set
name>
the only options?
Or are there other options also
No. If you leave off the VIA clause, the record area that receives the locked or deleted record is the one that is implicitly associated with the <set name>.
7. We do not need a LOCK statement before CREATE statement
imperatively but if done with a LOCK statement will it not have an
untoward result? Or is it not so?
If you consider wasting time and system resources an untoward result, then yes. When you LOCK a data set record, that loads the contents of that record into the program's record area and marks the record in the database as locked. Being locked means that it cannot be locked (using either SECURE or LOCK) by any other task in the system. If necessary, the locking task is blocked until all other tasks holding locks on that record release them (usually by doing END-TRANSACTION).
When you are inserting a new record into a data set, there is nothing to lock, so doing a LOCK first is a waste of time -- UNLESS you are running with INDEPENDENTTRANS set in the database [which you should be] and your application's locking protocol requires that some other record(s) in the same data set not be modified while the transaction that is doing the CREATE is running -- any records previously locked during the same transaction will retain their locks even if the same invocation of the data set is used to FIND/CREATE/LOCK some other record. Using a SECURE in this case is usually better than doing a LOCK, however, as shared-read locks are typically more system-efficient than write-locks.
Remember -- what you lock is not your program's record area -- it's the record in the database represented by that record area.
A CREATE verb merely initializes the program's record area according to the INITIALVALUE specifications in DASDL and marks it as storable. A record can be stored only if it was previously LOCKed or CREATEd.
--
Paul
.
- Follow-Ups:
- Re: Hello All
- From: Edward Reid
- Re: Hello All
- Prev by Date: Re: Issue in Gregory SITESUPPORT with DAYSTOT7 procedure
- Next by Date: Re: Issue in Gregory SITESUPPORT with DAYSTOT7 procedure
- Previous by thread: Issue in Gregory SITESUPPORT with DAYSTOT7 procedure
- Next by thread: Re: Hello All
- Index(es):
Relevant Pages
|
Loading