Been here, done this.
I do love these subs. They're 1000x more useful than "Wizards", since a Wizard writes an entire file not just one op you have to manually build a combined file, IMHO largely defeating the value of a Wizard. It's possible to build reusable Subprogs to build square/circular/spiral pockets from passed parameters, including finishing passes, and discard the Wizard method. This makes the code more flexible, and more readable than Wizard-generated "WTF does this do??" code, but the readability is still quite low.
There are two and only two ways of doing this.
The first is "parameters", which is a variable. The lable must be a number (not text, that would render the code too readable) and numbered within the acceptable range (at a bit over #5000, Mach has reserved a bunch for system numbers). Any math done on parameters must be enclosed in []. It is oddly illegal to have [-#5], it must be [0-#5] or [-1*#5].
#5=1
M98 P10 L3
M30
O10 (OUTWARD SPIRAL)
G01 X#5 Y0 F70
G12 X[#5+0.1] Y0. I-1. J0.
#5=[#5+0.1]
M99 ( SUBPROGRAM RETURN)
The second way is to use incremental moves inside a sub:
O11 (zigzag cut)
G01 X1
G01 X0 (right to left)
G91 G01 Y-0.1 (incremental step down)
G90 (cancel incremental mode)
G01 X1 (left to right)
G91 G01 Y-0.1 (incremental step down)
G90 (cancel incremental mode)
M99
At first this appears to be cleaner since it's not using these messy global parameters. The idea of using incremental runs into problems if you NEED to know the current XYZ location for part of an equation. There's no good way to get it. If it's passed as a parameter, the parameter is known. My example was a subprog to enlarge a rectangular pocket when passed the X0,Y0 center and the step size, always starting at top left corner. Didn't want to pass the current XY, thought I could just incrementally move to enlarge it. OK so I can do an incremental XY move to increase the start point one step out. Done. Say #10 is the X0 center. But then this top right move needs to G0 X[2*#10-Xcurrent]. The code can't access "Xcurrent" thus the solution appears to be impossible.
There was talk of reconfiguring Mach3 for "macro pumping" to make it possible to see Xcurrent, but it was not only an odd special config but sounded like it may not pass the correct value reliably.
EDIT:
OK, the macro pumping thing does seem to be possible, although there's some odd things you have to do to access it:
http://www.machsupport.com/forum/index.php?topic=11333.new;topicseen#new