Re: Re: Re: Can't spawn "cmd.exe": No error at

I do concurrent builds on many different Unix boxes from Windows, not by using threads, but by using remote shell (rsh client comes standard with Windows). The remote shell fires off a nohup Unix build script that writes its output to a Unix log file. After starting the Unix build script, the local rsh exits; this puts no strain on my Windows box at all and by firing off builds like this on 10 different Unix boxes, I am getting concurrent Unix builds; and I can check the status of the builds simply by running a remote shell that greps/tails the Unix log files. This whole process is easily automated via a Perl script.

On a system lacking remote shell (such as MVS perhaps) you might try using CPAN Net::Telnet module to automate everything you currently do by hand via telnet. This is not as nice as rsh because you need to "delay here" and "expect this", but it can be done (I have used this technique to control remote builds and regression tests on remote systems lacking rsh).

Comment on Re: Re: Re: Can't spawn "cmd.exe": No error at

Replies are listed 'Best First'.
Re: Re: Re: Re: Can't spawn "cmd.exe": No error at by mgibian (Acolyte) on Jul 18, 2003 at 16:46 UTC
I am already using Net::Telnet for running my Unix builds, currently synchronously, and my VMS builds, where I just submit a VMS batch job. The Unix side is only a small problem as they are very small bits and build very quickly. There is only modest improvement to be had by running these concurrently. I had thought using Perl threading might be a simple approach, but of course running them as "batch" jobs and going back to look at their results is probably the simplest way to go. The VMS builds take a great deal of time, both due to the amount of code being built, but also the slowness of the machines I am using. I do need to add code to go back and check logfiles for completion and success. Right now that is a manual process with the VMS builds. I am thinking Net::FTP might be the simplest way to go for checking the log files from batch jobs. MVS poses the greatest challenge. Note that these old beasts still use block mode terminal emulations for interactive use (the infamous "green screen"). While it appears possible to telnet to the various MVS environments, the server is not a standard telnet server. It would not make sense for it to be one since there is no "command line" environment for this beast, only the block mode full screen environment. And thus my question about automating things. It is not clear to me how one goes about this, yet I am sure it is being done. One strategy that makes sense is to submit batch jobs that do the work needed, and then use FTP to fetch results. But its not even clear to me how to do even this, nor that batch jobs can perform all the necessary tasks (such as shutdown a cics partition as one example).	[reply]
Re: Re: Re: Re: Re: Can't spawn "cmd.exe": No error at by eyepopslikeamosquito (Archbishop) on Jul 19, 2003 at 06:29 UTC
Just as rsh is a good alternative to telnet, rcp is a good alternative to ftp, for similar reasons, don't need to worry about interactivity issues and entering passwords. A heavier alternative is STAF, worth a look for MVS because STAF comes from IBM, though it may be overkill. We are currently actively looking at using STAF inhouse.	[reply]