Ready.
copycat82 is a case of plagiarism. It is a subset of NN73, the Macro E-nets. In every case, whenever copycat82 attempts to paste anything (which copycat82 cut from elsewhere) to Macro E-nets (NN73), it commits such a gross error that, we must necessarily remove it, and as a result, we arrive at only the Macro E-nets itself, again. i.e: The existence of NN73, is enough to point out the un-credibility (the unoriginality and/or the problems, in every case) of copycat82.
because of its plagiarism at the kindergarten level, copycat82 is essentially stuck at a fault-prone "least-common-denominator" of the prior art. As such, it is very much vague, and plain worthless. It is worse than trivial.
Tme macros of NN73 are very versatile, for intuitive compression of nets. NN73 presents tips for forming macro hierarchies (e.g: with the stack-processor), as well as extending the ordinary E-net primitives, with new input/output gate-logic. e.g: Jn-transition, Q-macro-location, etc.
Ten years later, copycat82 lacks any extras beyond NN73, although it is laxer, too. (e.g: E-net token-attributes are location-specific, but copycat82 lets "data" to be vaguely associated with macros, rather than with paths/locations.)
The two ways, which copycat82 attempts to cut-and-paste other (prior art) sources, to use with macros, both turn out to point at the ignorance of copycat82:
E-nets do not draw all of its formal listings in its net figures. When copycat82 cut-and-pastes those listings, it is only graph-clutter. Next, it leads to such problems of necessary separation of resolution vs. transition procedures, as discussed on this page.
Next, even copycat82 avoids that dump-all-to-the-net, in many cases, but that only increases the vagueness of the figures - especially, as the formal listings are nowhere, any more. i.e: copycat82 dumps a few data-name-, and data-type-name-rectangles, but most of the "data-type"s must be guessed. And to infer the data-links, we must search throughout other figures, too, when those data-items appear only as external-links - as in most subnets. (To find two of them would not suffice. There may be yet other subnets which use it. An exhaustive search may be needed, within all containers which may use that data-item. Do it for all such data-items.) In E-nets, where a shared token resides (with its attributes), is readily known, and for environment variables, we turn to the listings.
The Q-macro location of NN73, is a simple new type (of net element), as an example of an abstraction, with macros. The original E-net interpreted-abstraction capability with resolution-procedures through resolution-locations, was there, too.
copycat82's fake claim about Guttag's abstract data types, is only an absurd overspecification, which leads to a vague-duality between the resolution-procedures and whatever ADT-mechanism may compete to manage the token-flow through the net.
This is only a dump of rectangle-shapes, in the net figures. An ADT-rectangle (along with "data-item" rectangles) corresponds to a resolution-location. No example type-studies in copycat82, any way. And even the trivial suggestion of copycat82 to dump the data-type-names, to stand in place of the resolution-locations, do not exist in most, if any, figures - except a dummy name of "T" in a sample figure, where it is vague, too, because there are two data-items there, not only one.
An E-net is a single net, as copycat82 also advertises about itself, ten years later. But the E-net does not clutter, to represent every data-item-name, visually. It only standardizes the resolution (data-dependency) interface, and lets the modelers free to implement the procedures, elsewhere, textually.
copycat82's "single-graph" is both cluttered, and it is less-informative, too. It lists every data-item (token-attribute) as a separate rectangle, within the net figure, but it lacks any (visual) programmatic cue/standardization to represent the preference (to correspond to the E-net resolution locations). There must also exist, yet another graph, where the interdependency-network among the ADT operators, is represented - if there is any such thing. You have to read the/each program fragment, anyway.
Da80 does represent distributed-systems with (time-)Petri nets, extended with X-transition of E-nets, whereas copycat82/83 does not present anything new.
If contrasted to Da80, copycat82 chops the network-layer specifics, but does not introduce the application/OS specifics, either.
Even the "major example," of copycat82 is very trivial and faultfull. It is no role model for distributed systems modeling.
NN73 is basically what copycat82 has plagiarized from, The transition-start timing, single-graph, macro-ful representation, etc. were already, very similar to copycat82/83.
Noe&Nutt (1) Although copycat82 imitates also the SARA representation, Macro E-nets would fully cover that range of SARA-looks easily, already. After all, copycat82 only and faultfully, implements the input/output macros of SARA (and, or, xor, ...), copycat82 does not provide any extra software support (as found in the SARA software system), or any interface definitions, as SARA SL does. Such a trivial imitation is no sort of advance. Therefore, we may even omit any mention of SARA [SL].
[Noe&]Nutt (2) Next, we notice that, the implicit, but false, assumption of separate-verifiability of "component"s, which turn out to be only very vague macros, is also baseless. So, we may exclude VD78 relevance, too, when that extra is not referred-to.
Noe&Nutt (3) Next, even the macros of (Macro) E-nets are extra luxury, it appears, because other than the few entrance/exit macros, no workable/significant example macro is built, to provide any new behavior - except as uninterpreted abstractions. i.e: Everything is fittable within E-net limits - rather than mention Macro E-nets.
The semaphor example, and (the gravely problematic) monitor example, both being trivial, we may omit them. All of the input-macros of copycat82, except OR-input (which is itself, a very trivial, and problematic macro), turn out to be problematic, quasi-static subcases of E-net inputs (random-priority, priority-lost-after-first-pass, no-resolution-proc). And even the lock-place within "++-input", and the "sequential-output macro, do appear to entail the false expectations of copycat82, to imitate E-net structure (to imitate JSP, with "Petri nets" which were assumed as if E-nets).
For more about E-nets, or about the paper NN73 (Macro E-nets), these pages are readable.