The problem is that the status message and the text file I'm writing
report the proper code (ChaseDL=x); the system variable; however, does
not. I suspect that it has something to do with the variable called
EnviroString that I'm writing (ChaseDL=x) but if I convert the value of
x to a number or remove the "ChaseDL=" while keeping x as a string I
get a fatal error. Any suggestions?
--- start ---
proc main
string Destfile = "P:\Process\CNV\CHASE\Chase.txt"
string EnviroString
string EnvS
integer EnvN
getenv "ChaseDL" EnviroString ; do a get
statmsg EnviroString ; reports the number only
waitquiet 5 FOREVER ; leave it onscreen 5 sec.
execute "Chase2" ; execute child script
EnviroString = "ChaseDL=" ; set up EnviroString
EnvN = $EXITCODE ; pass the $EXITCODE
numtoStr EnvN EnvS ; convert to string
strcat EnviroString EnvS ; concat "ChaseDL=" + EnvS
statmsg EnviroString ; show it at the status line
strtoclip EnviroString ; write it to the clipboard
cliptofile TEXT Destfile ; save as a file
waitquiet 5 FOREVER ; leave it onscreen 5 sec.
clear ; clear the screen.
putenv EnviroString ; put the string in the sys var.
if SUCCESS ; report if successful
statmsg "WRITE TO ChaseDL"
endif
putenv EnviroString
if FAILURE ; report on failure
statmsg "COULD NOT write to ChaseDL"
endif
waitquiet 5 FOREVER ; leave it onscreen 5 sec.
pwexit ; bail out
endproc
--- end ---
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
I think I've got a feel for what you're doing, but I've got a couple
questions for you. What system variable are you checking that does not
have the correct return code? I'm assuming you mean $EXITCODE. It
seemed like everything worked OK when I ran your script and created a
CHASE2.WAX that simply had an exit statement and set an exit code.
I do have a couple suggestions that might make your job easier.
CHASE.WAX should set ChaseDL to some value, zero perhaps, before
CHASE2.WAX is executed. Otherwise you will get the exit code from the
previous execution of CHASE2. You may be taking care of this in
CHASE2, so this might not be a major thing.
I noticed that you use putenv EnviroString twice in a row, once
checking for success and a second time checking for failure. I would
recommend setting EnviroString once and using a if/then/else construct,
something like:
putenv EnviroString ; put the string in the sys var.
if SUCCESS ; report if successful
statmsg "WRITE TO ChaseDL"
else
statmsg "COULD NOT write to ChaseDL"
endif
Since putenv is going to report either success or failure, you should
be fine with the above construct.
Let me know if that helps any and if you have any further questions.
I have now changed the system variable to "errorlevel" since "ChaseDL"
did not seem to be working. Same result, e.g. no change to the
environment variable AT ALL.
Procomm was such a good product until they decided to start using
TAPI. Now I have no direct control of the modem and no way to pass
error events to the DOS prompt. Symantec wants to charge, by the hour,
for support on ASPECT. Since this isn't even covered in the manual and
the only example in the help file is woefully incorrect I can only
assume the intention of the vendor was to make a few extra bucks off of
the product. I have no intention of paying extra dollars to get tech
support for a product that is less than thirty days old.
> I think I've got a feel for what you're doing, but I've got a couple
> questions for you. What system variable are you checking that does
> not have the correct return code? I'm assuming you mean $EXITCODE.
> It seemed like everything worked OK when I ran your script and
> created a CHASE2.WAX that simply had an exit statement and set an
> exit code.
Initially I was checking both ChaseDL and errorlevel. Neither returns
the right code. $EXITCODE is indeed being used to pickup the
appropriate exit code from Chase2.was. A copy is attached below.
proc main
integer DayWeek ; Day of the week.
integer DayYear ; Day of the year.
integer LeapYear ; Leap year flag.
string Day ; Day of week as string.
string messCode ; Place holder for return value.
string SendIt ; concatinated string to send.
ltimemisc $LTIME DayWeek DayYear LeapYear
weekdaystr DayWeek Day ; Get day of week in string form.
substr MessCode Day 0 3 ; Extract hypothetical three digit
; code, maybe encased in brackets.
; "[123] Message", for example.
strcat SendIt "fname."
strcat SendIt MessCode
strcat SendIt "^M"
dial DATA "Hast" ; Dial Chase Bank entry.
while $DIALING ; Loop while dialing.
endwhile
if $CARRIER ; See if we're connected.
transmit "^M" ; Send a carriage return
else
Exit 1 ; if no CRLF return a one
endif
waitfor "^M" 5
waitfor "Welcome to HAST BANK OF MONTANA - BILLINGS" 5
if FAILURE
Hangup
Exit 2
endif
waitfor "^M" 5
if FAILURE
Hangup
Exit 3
endif
waitfor "Company #:" 5
if FAILURE
Hangup
Exit 4
else
transmit "company^M"
endif
waitfor "Password:" 5
if FAILURE
Hangup
Exit 5
else
transmit "password^M"
endif
waitfor " Enter Selection: " 5
if FAILURE
Hangup
Exit 6
else
transmit "d"
endif
waitfor "Your Choice" 5
if FAILURE
Hangup
Exit 7
else
transmit "z"
endif
waitfor "File name? " 10
if FAILURE
Hangup
Exit 8
else
transmit SendIt
endif
waitfor " Enter Selection: " 5
if FAILURE
Hangup
Exit 9
endif
transmit "g"
waitquiet 5 FOREVER
Exit 0
endproc
The problem is the way putenv is coded - it apparently can add
new vars but if you shorten/lengthen an existing var, it cannot
handle the change. In this case, the env structure must be
shifted around to accommodate the change in the string length.
The "add a new var" case is easier since it just appends a value.
Here's a test. Go to DOS, type SET and pick some var in the middle
somewhere. For example my SET output displays "BC=4". Code a script
to change this var (make it longer) like :
proc main
putenv "bc=123"
endproc
I can almost guarantee you will get a Fatal Exception! Yet, if you
pick a var nmae that is not used, it will probably work fine.
In article <7k3iqd$bf$1...@nnrp1.deja.com>,
wjb...@my-deja.com wrote:
> John,
>
> I have now changed the system variable to "errorlevel" since "ChaseDL"
> did not seem to be working. Same result, e.g. no change to the
> environment variable AT ALL.
>
Mark may I get a copy of your bug list please?
Thank you. . .
John Leather