@tom-henderson
Forum Replies Created
-
AuthorReplies
-
The exec command requires a list, and you’re giving it what amounts to a string. So it’s trying to find and run a program named c:\dir\pgm.exe “parm1” “parm2” “parm3”, when you want it to run a program named c:\dir\pgm.exe and pass in the parameters parm1, parm2, and parm3. The other wrinkle is that it the list needs to be flattened, that is, at the same level as the exec command, not just contained in a variable. Otherwise, your program will see a single parameter rather than three separate parameters.
Fortunately, the fix is easy. The eval command will not only run any other TCL command, but also flatten out the list structure for you. Just issue the command like this:
eval exec c:\dir\pgm.exe “parm1” “parm2” “parm3”
Essentially, any time you want to construct a command programmatically, then execute it, just use the eval exec combo.
BTW, I generally find it easier to use single forward slashes rather than double the backslash. Of course, if you’re passing a pathname to a native DOS/Windows command, you may not have any choice…
Something like that. First, put your arguments into a list variable, then use the eval command to call your proc with that list. The eval command “flattens” your list so they look like individual variables. Something like:
set listArgs
eval ECP_Send_Email $listArgs
The eval command will let you construct just about any command dynamically, then call it. It works with lists, though, not strings. Create the command as a list, then use eval.
But if you’re doing a proc call, you want to be sure that the list you’re passing to the proc has the same number of arguments as the proc is expecting, or you will get a run-time error.
I should probably clarify that Visual-Regexp IS written in TCL, which is why I tend to use it for TCL regular expressions. Regexplorer is probably just as good for regular expression exploring, but it’s written in Perl… If you dump to the /dev/null file, the output goes nowhere (which is faster than storing in a file), you don’t get the side effect of a really big file, and you still get the number of messages reported to you. So hcidump -r -s 7 target_connection /dev/null should report the number of messages
You may be able to do the same thing on Windows by specifying the output file as NUL:, but I have no way of testing it.
There’s a tool called Visual-Regexp which allows you to play around with regular expressions and matching. I use it every now and then when I’m working on a tricky one, or when the regular expresssion I just created somehow fails to match anything. See
http://wiki.tcl.tk/7992 for details. The interface takes a little getting used to, but once you get the hang of it…Don’t confuse with Regexplorer, which is a similar tool written in Perl.
We do something similar to send an email with a legal disclaimer in bold text. The key is that email only really works with plain text, so the message has to be properly encoded with MIME for it to work correctly. The format for HTML email is to MIME-encode the message as multipart/alternative, then supply the message as an HTML version (your document) and a plain text version. Conceptually, each version carries the same message, but nothing really enforces that. Spammers will often send out email where all the message is in the HTML part and the plain text part contains little or nothing.
The reason for this is so someone can read your email whether the email client supports HTML email or not.
Anyway, assuming that you a) have tcllib installed, which includes the MIME and SMTP extensions, and b) have the HTML and plain-text message in an HTML file and a plain-text file named nogo.html and nogo.txt, and c) change the email address and email server names to real-world values, this code should work.
Just one word of caution about the format statement. It sees numbers that start with a zero as octal numbers, so if you’re asking it to say, turn 0134 into 000134 it will bomb. The solution is simple, though: Just wrap the value with a [string trimleft 0] to first trim all the leading 0’s, if any, before formatting the number with the right number of leading zero’s. For example:
set xlateOutVals [format “%06s” [string trimleft $xlateInVals 0]]
If you’re sure the values will never have a leading zero, then it’s not necessary. But if they ever might….
I’m not familiar with Fileset/FTP in Cloverleaf, but many FTP programs have trouble with some quirks in how the AS400 handles FTP.
For a database file, you would need to request the file as LIBRARY/FILE.MEMBER, which means that, for example, the file BADPLPP in library BSYDTAA would be specified as BSYDTAA/BADPLPP.BADPLPP. Most database files have one member, usually named the same as the base file name. However, they can have multiple members, and since the member name follows the period, it looks to some OS’s and FTP programs as if it’s an extension. If Cloverleaf is looking for a particular set of allowed extensions, that could really throw it.
This only applies to the database files. Other files in the IFS follow much more normal naming conventions.
There is alternate naming convention for database files, which can be selected with the NAMEFMT 1 command (from the client, usually given as QUOTE SITE NAMEFMT 1). Under this naming convention, database files are all in the /QSYS.LIB directory, all the library names end in .LIB, all the FILE names end in .FILE, and all the member names end in .MBR. So the same file example would be /QSYS.LIB/BSYDTAA.LIB/BADPLPP.FILE/BADPLPP.MBR.
In either case, the
member is really the thing treated like a file, and thefile is treated as a directory. The only difference between the two naming formats is, well, the naming format.All of which is to say, if the Cloverleaf FileSetFTP doesn’t support this, you may be able to give it a few more options to make it do what you want.
One convenience tip: If the first thing you do is to CD to a certain directory expressed in the alternate naming convention, the AS400 FTP server will switch to that convention for you rather than requiring you to give the NAMEFMT 1 command. This gets around those FTP clients which make it hard to supply customized commands to an FTP server.
Of course, then there’s the special case of AS400 SAVE files….
set day_of_week [clock format [clock seconds] -format “%A”] Which looks more complicated, but eliminates having to exec another process just to get the date
This returns the full day of the week. If you want just the 3-letter abbrevation (Sun, Mon, Tue, etc.), use the “%a” format code
Usually, when you log in by telnet, the server starts up a shell. The shell should read an initialization file, which should set up the environment for you, allowing you to use setroot, setsite, and all the hci- commands. So the problem is that this is not happening for you. I’m not sure if your server is running Unix or Windows, but in Unix servers, Cloverleaf typically sets your login shell to the Korn shell (ksh), and the initialization file is named .profile (with a leading period).
So your long term fix is to find why the .profile file is not being read to set up your environment when you log in. Perhaps you’re not logging in as hci or hcitest, which Cloverleaf sets up for you. Or perhaps you’re using a different login shell.
A quick workaround is to immediately after login type the command source .profile (note the leading period). This should set up the environment for you.
If you’re not using the ksh login shell, though, setroot and setsite will not be properly read in, and you’ll have to do that manually as well. You can do that by changing to the “kshlib” directory just under your Cloverleaf root, and typing source *
We do something similar for radiologists and transcribed documents. Ours is not done through Cloverleaf, because it’s primarily driven by the transcription system, which currently doesn’t send anything through Cloverleaf. We query the transcription system (Softmed, through their Report Generator) to get the transcriptions for the previous day, run a query to get demographics for those records (in a fixed file format that the Radiology doctors group just had to learn to interpret), then we send them that file as an encrypted email attachment, and route the transcribed documents to them as encrypted PDF’s.
And that was the easiest way to do it….
🙂 I won’t mourn the Java GUI’s passing … but I do mourn the TCL/TK GUI’s passing. Seems to me Java has always been much better for the server end. The only problem with using a native-Windows GUI is that it’s only good for Windows clients. a) Some people use … and prefer … Linux or Unix workstations
b) You’ll never be able to run the Windows GUI on the Cloverleaf box in a pinch …. unless you’re running Cloverleaf on Windows
c) Personally, I prefer a long-running GUI on the Cloverleaf system that I (or someone else) can access by VNC from home or work, whether to change anything or just to monitor the interfaces. Of course, I already avoid the Java GUI in favor of the old “Network Monitor”, since the Java GUI is not recommended to be run on the Cloverleaf server if you’re on AIX. But with a Windows client it will not only be “not recommended”, but also, “not possible”.
Granted, the old TCL/TK GUI’s were dated. But then, they were old. The Java GUI was better organized and better appearing, but seemed to lose some functionality and be noticeably slower. And not very VNC-friendly, since it seemed to spend so much of its time redrawing itself.
It’s very possible to make TK gui’s look modern and be functional, with probably less effort still than most tookits. And you get a cross-platform GUI in the bargain. And since TK uses native components where possible, it would still look like a pure-native Windows GUI.
Besides, using the new “Starkit” functionality available in TCL now, client installation could be reduced to copying two files to the client and setting up a shortcut.
Strange that I would argue for TCL/TK, since it’s only because of Cloverleaf that I ever learned TCL ….
😕 😈 -
AuthorReplies
