Ready.
An E-net transition is/represents activity. As soon as it is (fully) enabled, it starts, i.e: there is no wait-before-firing time, separate from the transition-time.
In copycat82, it is the section "3.2.6. Component Internal Structure." which corresponds to E-net transitions (both primitive- and macro-transitions). The first paragraph of it, is even with the same order of E-net, in the order it discusses, the 1)schema, 2)time 3)tranproc. The latter two paragraphs are about macros.
The copycat82 does not discuss the boundary/conditions, where a macro is different from a properly reduced subnet/transition, and thereby, when we MUST expand it, to be correct. Let alone, how you would do it, algorithmically/mechanically. i.e: It does not provide the rules a designer must follow (VD78 does), and does not automatize it, either (SARA/UCLA does).
See: macro/subnet (prior art).
The first paragraph of that section, is even trackable with the E-net formality, in
the "(s,t(a),q)" order (schema, time, tranproc).
The same as E-nets (lists input/output locations, and maps input-to-output), except that the notation is imitative of SARA - with operator-signs, instead of E-nets schema-names. e.g: Instead of the E-net notation "F(in, out1, out2)", writes the SARA'ish "(in, out1*out2)" - where the "*" is the "and" operator, that corresponds to the F-transition of E-nets, at the output side.
Every E-net transition lists its in/out locations as parameters. E-net primitives (and macros) are able to nest recursively, in a hierarchy, or network, although E-net fine practice is to abstract, with resolution procedures, and/or with macros. For example, there is the Q-macro location, a queue/stack. It may re-order the inbound tokens, too. We may instantiate a Q-macro with a capacity of N tokens e.g: Q20[12] is with a quota of 20 tokens (& any token with 12 attributes).
Another page discusses the part of the plagiarism of copycat82, about the macros for peripheral, input/output patterns.
Exactly E-nets, in immediately-firing, but lacks the rest. It is mystifying how it would be run. On a page in copycat82, in a line, or two, refers to time-Petri--nets as a possibility for simulations, but in fact, with the already adopted E-net behavior of starting immediately, the time-Petri-nets behavior is NOT a possibility.
cf. Da80. Presumably, copycat82 thought of imitating Da80, about this, too, but ignored that, Da80 had not adopted E-nets timings, at all. Da80 employs the notion of time, exclusively from time-Petri-nets. (Well, then again, that is pointing at further Danthine'ism, too!)
E-nets transprocs (but how would it really be simulated deterministically, with data, if time is not specified explicitly? (Only with J-tran synchronizations?))
The latter two paragraphs are about macros. The overall vagueness is, in fact, inherent in (i.e: the real case about) copycat82, because it confuses macros with reductions with interpreted/uninterpreted abstractions.
It, ignorantly, collapses the idea of net-nodes with macros, and never provides any algorithm to sort them out, either. As such, at the end, it is only a vague mess, unverifiable by a Petri net verifier. e.g: In SARA terms, it is an attempt to verify SARA SL modules with their multiple sockets, as if such a module, were a control-node. Or, in E-net terms, it is an attempt to verify (with Petri net reachability test) without macro-expansion, with false-assumptions that take arbitrarily-shaped macros, as if a primitive. Read about the myths of copycat82.