Exspans Systems Inc Logo home
 
Forum
Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #1 
AutoMan V3.3 contains numerous internal improvements to enhance efficiency as well as some language enhancements. It also has a new interface capability to provide real time updates to monitor consoles that will be available in AutoMate V3.3.

The interpretation of IF statements has been enhanced so that the DO - END construct is no longer needed for single statement options. Thus:

IF &I = &A LET &B = 1
ELSE LET &B = 2

The names of command lists on RUN statements may now be or contain variables.

The ENABLE ad DISABLE statements may now receive variables for the object names.

CART and console ID are passed with all user commands and responses sent using them.

User data files may be allocated and written to from GAL scripts.

0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #2 
Download AutoMan V3.3 http://forums.exspans.ca/file?id=2627471

Installation Instructions http://forums.exspans.ca/file?id=2627472

The manual library is too large to put up here for download. If you need more manuals shoot off an email to support.

 
Attached Files
pdf AutoMan_V33_Installation.pdf (285.93 KB, 3 views)

0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #3 
Update AutoMan V3.3 now supports parameters to Command List.

eg

MSG=ID09R445I
VAR &JNAME LEN 8
RUN CMDPROC (&JNAME) ASYNCH

Command Lists operate as either a subroutine or a subtask depending on the SYNCH/ASYNCH option

When the Command List receives the parameter it is exactly as when the message was received, even though the message may be executed multiple times before any given instance of the command list ends.
0
Zamin

Avatar / Picture

Member
Registered:
Posts: 67
Reply with quote  #4 
The parameter passing on command lists is very useful and it did not take me long to realize just how much effort it saves. I never did like enqueuing from message intercepts to ensure that global variables were not reused. Now that I have tried it I do not want to wait for your upgrade cycle and would very much like to keep the demo code or get an early release.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #5 
I've wanted command list parameters and local variables for a long time.  Once someone understands parameters and local variables, they will wonder how they got along without them.
__________________
zboxassist
0
Grazillda

Avatar / Picture

Member
Registered:
Posts: 48
Reply with quote  #6 
I have quietly been using V3.3 since the beta and now have completely upgraded. It is a shame that it took so long to get to this stage. Like zboxassist says I don't know how I manage before. I have eliminated quite a bit of code and it is quicker.
0
Zamin

Avatar / Picture

Member
Registered:
Posts: 67
Reply with quote  #7 
Text replacement in command list names and parameters has made for the possibility of very obscure looking code. I have some, inherited from a very old system where message ids were 8 long and corresponded to a pdf member name. I would not do it this way now, but to accommodate this inherited code, while it is assimilate into the full automation scenario, lets me do this:

MSG=JXY001W
VAR MNAM LEN 8 LOCAL
LET MNAM = $$MSGID
RUN MNAM ASYNC

with exactly the same piece of code for every one of the affected message ids.

This picks up the message identifier, moves it to a variable them uses the variable as the command list to run. Thus when this message is seen a command list with the same name will be run.
0
Zamin

Avatar / Picture

Member
Registered:
Posts: 67
Reply with quote  #8 
Quote:
Originally Posted by Grazillda
I have quietly been using V3.3 since the beta and now have completely upgraded. It is a shame that it took so long to get to this stage. Like zboxassist says I don't know how I manage before. I have eliminated quite a bit of code and it is quicker.


I have had the permanent copy running for a month now and it does seem to be about 30% faster loading. The actual time for the OS and all my subsystems to activate is about the same though. The fully active system is up in about 3 minutes, so while AutoMan itself seems to be faster, the other subsystems still take the same time.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!