
                    Programming/using OS/2 REXX      (echo)

                 Saturday, 27-Nov-1999 to Friday, 03-Dec-1999

+----------------------------------------------------------------------------+

From: MIKE RUSKAI                                       25-Nov-99 05:24:00
  To: PETER KNAPPER                                     27-Nov-99 00:31:24
Subj: Copying files and EA's...

Some senseless babbling from Peter Knapper to Harry Bush
on 11-24-99  20:29 about Copying files and EA's......

 PK> Hi Harry,
 
 PK> So as far as REXX is concerned, I guess that using 
 PK> SysCopyObject() with full path/filenames for copying 
 PK> over the LAN would probably be reasonably
 PK> safe, as far as copying EA's are concerned?
 
 HB> Do you mean using full path name kinda 
 HB> \\computer\directory\file instead of Object ID?  

 PK> Hmmm, I was actually thinking of copying using drive letters rather
 PK> than a UNC, however I am now not sure that I would want EA's copied in
 PK> all cases..;-) I see others have comented on this also, so I guess I
 PK> need to actually do some tests myself to see what happens.
 PK> For example, the EA's for a REXX script may contain machine specific
 PK> data (EG: drive letters) that would probably need to change on another
 PK> platform. Without EA's REXX would automatically re-build it anyway, but
 PK> if the REXX code HAD to change then there is not much point in copying
 PK> EA's... 

The tokenization code doesn't contain any hard-coded values that aren't
also in the source.

That is, if you don't have the drive letter hard-coded in, but retrieve it
from a function or user input, there's no need to retokenize the code.

Of course, I think the primary point you seem to be trying hard to miss is
that EA's are taken care of automatically, and short of creating a new file
to which you write all of the data from the old file, you can't avoid
copying them when they are capable of being copied.

The upshot is, you're wasting your time thinking about a non-issue.

Mike Ruskai
thannymeister@yahoo.com


... Excuse me, miss?  Miss!?  Sorry, I have a cold.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
 * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)

+----------------------------------------------------------------------------+

From: Sergey Popov                                      20-Nov-99 15:38:17
  To: Eddy Thilleman                                    27-Nov-99 06:01:28
Subj: Re: seek

ਢ , Eddy!

10  99 07:57, Eddy Thilleman -> All:

 ET> BeginOfFile = "seek =1"

 ET> check = stream( file, 'C', BeginOfFile )    /* seek to begin of file */

 ET> but this results in error messages. I don't understand that.

Try following:

check = stream( file, 'C', Interpret(BeginofFile)) /* :-) */


                Sergey Popov.
--- GoldED/W32 3.0.1
 * Origin:  祣, , ? (2:5085/1.104)
140/1

+----------------------------------------------------------------------------+

From: George White                                      25-Nov-99 10:54:25
  To: Eddy Thilleman                                    27-Nov-99 06:01:29
Subj: FrontDoor/Mailer and Re

Hi Eddy,

On 22-Nov-99, Eddy Thilleman wrote to Francois Massonneau:


 ET> Hello Francois,

 ET> 20 Nov 99 11:01, Francois Massonneau wrote to David Noon:

 FM>> As I do not know whether or not the first message I posted has
 FM>> been sent (France is no longer connected to the rest of the world
 FM>> ;-( ), i post it again as I found another feed. I hope I will be
 FM>> sent this time.

 ET> your message was already sent out on 11 November 1999. :)

That one didn't make it out to here so it's just as well he re-posted
it, David wouldn't have got it otherwise.

George

--- Terminate 5.00/Pro 
 * Origin: A country point under OS/2 (2:257/609.6)

+----------------------------------------------------------------------------+

From: George White                                      26-Nov-99 08:41:03
  To: David Noon                                        28-Nov-99 06:01:14
Subj: FrontDoor/Mailer and Re

Hi David,

On 25-Nov-99, David Noon wrote to Francois Massonneau:


 DN> Hi Francois,

 DN> Replying to a message of Francois Massonneau to David Noon:

 FM>> As I do not know whether or not the first message I posted has
 FM>> been sent (France is no longer connected to the rest of the world
 FM>> ;-( ), i post it again as I found another feed. I hope I will be
 FM>> sent this time.

 DN> I saw your earlier message last month and replied.

The message you are replying to here was his re-post of his reply to
your reply you refer to above.

<snip>

 DN> It could be. I no longer have your code. If the variable
 DN> DialpuLogFile contains the full path/filename of your log file
 DN> then the PingServer subroutine will need to access it in order to
 DN> write its results to the correct log file. In such a case you
 DN> should either pass it as a parameter or expose it on the PROCEDURE
 DN> statement

I've got all the thread (as received at 2:257/609) in my message base
if you want it.

George

--- Terminate 5.00/Pro 
 * Origin: A country point under OS/2 (2:257/609.6)

+----------------------------------------------------------------------------+

From: David Noon                                        27-Nov-99 09:50:07
  To: Larry Snider                                      28-Nov-99 06:01:14
Subj: SysCopyObject

Hi Larry,

Replying to a message of Larry Snider to All:

 LS> Could someone please provide me with a working example of
 LS> SysCopyObject using fully specified file names?  For some reason, I
 LS> cannot get it to work.

 LS> I've tried it this way:

 LS> call SysCopyObject('e:\popuplog.os2', 'e:\SCO_popuplog.os2')

What you are trying to do here is copy the file and re-name it as you go. The
SysCopyObject() function won't do this, as it uses the SOM method supplied by
the WPS for its drag-and-drop copy operations.

Instead, you will need an extension DLL that provides an interface to the
DosCopy() API. I use REXXLIB, from Quercus Systems Inc., to do this. You will
likely find RxExtras and YDBAUTIL also offer some similar facility.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.24.1
 * Origin: The man who broke the bank at Monte Carlo (2:257/609.5)

+----------------------------------------------------------------------------+

From: David Noon                                        27-Nov-99 10:04:22
  To: George White                                      28-Nov-99 06:01:14
Subj: FrontDoor/Mailer and Re

Hi George,

Replying to a message of George White to David Noon:

 GW> I've got all the thread (as received at 2:257/609) in my message base
 GW> if you want it.

Thanks, but I simply did a re-scan of the echo and got them from Vince.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.24.1
 * Origin: The man who broke the bank at Monte Carlo (2:257/609.5)

+----------------------------------------------------------------------------+

From: David Noon                                        27-Nov-99 18:44:15
  To: Peter Knapper                                     28-Nov-99 06:01:14
Subj: REXX FtpPing.

Hi Peter,

Replying to a message of Peter Knapper to David Noon:

 PK> When talking to Francois Massonneau recently the subject of performing
 PK> a PING came up, so you may have an answer for this. 

 PK> Most of the REXX FTP functions appear to be implemented with some
 PK> quite lengthy timeouts, and it can take 1-2 minutes to decide that
 PK> the remote end is not contactable. I tried to "test" for this using a
 PK> single FtpPing, however if the destination/target system is not
 PK> contactable, FtpPing suffers from the same long timeout. Do you know
 PK> of a way to alter the REXX FTP timeout period to something like 10-20
 PK> seconds rather than 2 minutes?

You can certainly do this with raw socket functions. A ping is simply a RPC to 
the remote host, and you can specify your timeout in which you expect that RPC 
to respond. There is sample code in the OS/2 Warp 4 Developer's Toolkit
documentation for the OS/2 TCP/IP Toolkit 4.1 that will get you started.

 PK> Alternatively, can you (or someone else) suggest some REXX Sockets
 PK> code to perform the equivalent task, if the timeout periods can be
 PK> controlled from there?

I don't know much about RxSock.DLL, but I would doubt that it would offer such 
a low level API. I think you will need to use a compiler or assembler to do
this. Of course, you can always wrap the resulting code in a few lines of REXX 
calling interface and make it an extension DLL.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.24.1
 * Origin: The man who broke the bank at Monte Carlo (2:257/609.5)

+----------------------------------------------------------------------------+

From: MIKE RUSKAI                                       28-Nov-99 05:55:00
  To: PETER KNAPPER                                     28-Nov-99 18:20:24
Subj: REXX FtpPing.

Some senseless babbling from Peter Knapper to David Noon
on 11-27-99  09:25 about REXX FtpPing....

 PK> When talking to Francois Massonneau recently the subject of performing
 PK> a PING came up, so you may have an answer for this. 

 PK> Most of the REXX FTP functions appear to be implemented with some
 PK> quite lengthy timeouts, and it can take 1-2 minutes to decide that the
 PK> remote end is not contactable. I tried to "test" for this using a
 PK> single FtpPing, however if the destination/target system is not
 PK> contactable, FtpPing suffers from the same long timeout. Do you know of
 PK> a way to alter the REXX FTP timeout period to something like 10-20
 PK> seconds rather than 2 minutes? 
 PK> Alternatively, can you (or someone else) suggest some REXX Sockets
 PK> code to perform the equivalent task, if the timeout periods can be
 PK> controlled from there?

I don't think RxFTP allows for setting the timeout value.

You won't be able to use RxSock for pinging, either, because it doesn't
support ICMP packets.

To have a functional ping in REXX (without grabbing the output of PING.EXE)
would require writing another DLL, that'd allow for a timeout.

Mike Ruskai
thannymeister@yahoo.com


... Humor is the ability to laugh at ourselves.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
 * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)

+----------------------------------------------------------------------------+

From: Francois Massonneau                               27-Nov-99 21:07:23
  To: David Noon                                        29-Nov-99 03:33:21
Subj: FrontDoor/Mailer and Re

Hello David!

Replying to a message of David Noon to Francois Massonneau:

 DN> I saw your earlier message last month and replied.

I didn't see it ;-( Sorry. I'm just connected again to those OS/2 echoes thru
a new feed in Germany.

 DN>>> This means it will terminate after one poll. Also, the conditional
 DN>>> leave statement (mentioned above for its IF part) will need to be
 DN>>> changed to:

 DN>>>      if files.0 = 0 then
 DN>>>          exit 0 /* was leave */

 FM>> I did that, but it doesn't work as expected.
 FM>> If I put "exit 0", when no more files are in the subdirectory, the
 FM>> window is closed, but the windows that launched the script and the
 FM>> one where the dialer is running are still opened and wait for the
 FM>> signal the script must send to tell everything is done. so I left
 FM>> the "leave" statement.

 DN> This should cause the REXX program to terminate in error. The LEAVE
 DN> statement applies to the context of a DO group, and removing the DO
 DN> FOREVER removes that context.

Yes, but the DO FOREVER I removed was the one at the beginning of the rexx
file, the "leave" statement I have, applies to another DO FOREVER, just three
lines above the leave statement, 

 DN>>> So you are no longer using a semphore file.

 FM>> It's no longer a semafore file, but the script sends a signal to
 FM>> HWAIT.

 DN> What kind of signal? Does it post an event semaphore (not a file)
 DN> instead?

HSTART sends a signal to another program named HWAIT which is waiting for this 
signal. This allows you to launch a program or a CMD file from a DOS batch
file (and vice versa), then make that Dos batch to wait for the end of the CMD 
file when the later sends a signal to hwait which is waiting. 

 FM>>> 3) At the end of the script, I saw you write two times (one before
 FM>>> and one after the subroutine "StopDialler"), the following lines : 
 FM>>> /* Reset elapsed time counter */  CALL TIME 'R' RETURN I suppose
 FM>>> one is for the subroutine StartDialler, and the second one is for
 FM>>> the subroutine StopDialler. Is it a code to give the time on line ?

 DN>>> It is part of that code.

 DN>>> There should be a TIME('E') call somewhere in the StopDialler
 DN>>> subroutine that should display the elapsed time.

 FM>> Where ?

 FM>>   ADDRESS 'CMD' KillDialer
 FM>>   CALL LogMsg 'dialer, if running, is killed.'
 FM>>   CALL LogMsg 'Dialer disconnected after ' || TIME('E') || '
 FM>> seconds.'

 DN> ... right here! (Above)

It doesn't work ;-(
I tried :
ADDRESS 'CMD' KillDialer
CALL LogMsg 'dialer, if running, is killed.'
CALL LogMsg 'Dialer disconnected after ' || TIME('E') || ' seconds.'
CALL TIME('E')
and :
ADDRESS 'CMD' KillDialer
CALL LogMsg 'dialer, if running, is killed.'
CALL TIME('E')
CALL LogMsg 'Dialer disconnected after ' || TIME('E') || ' seconds.'
but it didn't work. I still have :
22 Nov 1999 09:32:54  Dialer disconnected after 0 seconds.

 FM>> I saw a problem with the log generated.
 FM>> A file is created in my root directory, named DIALUPLOGFILE. In it I
 FM>> have all the sentences that should be put in the dialup.log file,
 FM>> but the sentences are the ones generated by the PingServer
 FM>> Procedure. It seems that a "CALL LogMsg ..." statement contained in
 FM>> the PingServer procedure is not written in the dialup.log file, but
 FM>> in a dialuplogfile file in my root directory. Is it because I have
 FM>> the beginning of the procedure written that way :  PingServer:
 FM>> procedure   call LogMsg 'PingServer starting'   .../. instead of :
 FM>> PingServer: PROCEDURE EXPOSE DialupLogFile    call LogMsg
 FM>> 'PingServer starting'   .../.

 DN> It could be. I no longer have your code. If the variable DialpuLogFile

Yeap, it was the culprit :-) now this problem is solved.

Do you have an email address where I can send this rexx script, as I modified
it to follow your instructions ?

Bye, Francois!


Email: fmas@celtes.com
Web  : http://www.worldnet.net/~island/

---
 * Origin: Island's BBS, a Node in the Atlantic Ocean (2:326/2)

+----------------------------------------------------------------------------+

From: Peter Knapper                                     29-Nov-99 19:12:06
  To: David Noon                                        29-Nov-99 08:06:00
Subj: REXX FtpPing.

Hi David,

 DN> I don't know much about RxSock.DLL, but I would doubt 
 DN> that it would offer such a low level API. I think you 
 DN> will need to use a compiler or assembler to do this. Of 
 DN> course, you can always wrap the resulting code in a few 
 DN> lines of REXX calling interface and make it an 
 DN> extension DLL.

From your comments and other replies it appears that I would have to drop all
the way back to C to pick up the control over timeouts.....;-( Its not exactly 
an important requirement so may have to put this part of the project on the
back-burner, my meddling with REXX extension .DLL's has not exactly been a
great success story so far.

Thanks anyway...............pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)

+----------------------------------------------------------------------------+

From: Peter Knapper                                     29-Nov-99 19:18:09
  To: Mike Ruskai                                       29-Nov-99 08:06:00
Subj: REXX FtpPing.

Hi Mike,

 PK> Alternatively, can you (or someone else) suggest some REXX Sockets
 PK> code to perform the equivalent task, if the timeout periods can be
 PK> controlled from there?

 MR> I don't think RxFTP allows for setting the timeout value.

Thats the conclusion I came to...

 MR> You won't be able to use RxSock for pinging, either, because it doesn't
 MR> support ICMP packets.

I thought that may be the case in the quick glance I did over RxSock, but I
was hoping that someone might come up with an option on it...

 MR> To have a functional ping in REXX (without grabbing the 
 MR> output of PING.EXE) would require writing another DLL, 
 MR> that'd allow for a timeout.

And we end back at Davids suggestion......;-)

Thanks for the input on this...........pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    28-Nov-99 10:03:20
  To: Sergey Popov                                      30-Nov-99 21:01:14
Subj: seek

Hello Sergey,

20 Nov 99 15:38, Sergey Popov wrote to Eddy Thilleman:

SP> check = stream( file, 'C', Interpret(BeginofFile)) /* :-) */

I didn't think of interpret... thanks

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... C:\DOS\RUN     C:\WINDOWS\CRAWL     C:\OS2\FLY
--- GoldED/2 3.0.1
 * Origin: Windows95 is a graphic DOS extender (2:280/5143.7)

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    28-Nov-99 10:48:13
  To: George White                                      30-Nov-99 21:01:14
Subj: FrontDoor/Mailer and Re

Hello George,

25 Nov 99 10:54, George White wrote to Eddy Thilleman:

ET>> your message was already sent out on 11 November 1999. :)

GW> That one didn't make it out to here

strange, I got the first one too

GW> so it's just as well he re-posted it, David wouldn't have got it
GW> otherwise.

and David got the first one too :)

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... OS/2 users have 'Extended Attributes'
--- GoldED/2 3.0.1
 * Origin: Windows95 is a graphic DOS extender (2:280/5143.7)

+----------------------------------------------------------------------------+

From: George White                                      28-Nov-99 12:18:22
  To: David Noon                                        30-Nov-99 21:01:14
Subj: FrontDoor/Mailer and Rexx

Hi David,

On 27-Nov-99, David Noon wrote to George White:

 GW>> I've got all the thread (as received at 2:257/609) in my message
 GW>> base if you want it.

 DN> Thanks, but I simply did a re-scan of the echo and got them from
 DN> Vince.

That saves me the effort of digging them out of my message base :-).

George

--- Terminate 5.00/Pro 
 * Origin: A country point under OS/2 (2:257/609.6)

+----------------------------------------------------------------------------+

From: David Noon                                        30-Nov-99 21:29:12
  To: Francois Massonneau                               01-Dec-99 09:34:04
Subj: FrontDoor/Mailer and Re

Hi Francois,

Replying to a message of Francois Massonneau to David Noon:

[snip]
 DN>> What kind of signal? Does it post an event semaphore (not a file)
 DN>> instead?

 FM> HSTART sends a signal to another program named HWAIT which is waiting
 FM> for this signal. This allows you to launch a program or a CMD file
 FM> from a DOS batch file (and vice versa), then make that Dos batch to
 FM> wait for the end of the CMD file when the later sends a signal to
 FM> hwait which is waiting.

Ok, that's an event semaphore.

[snip]
 FM> Do you have an email address where I can send this rexx script, as I
 FM> modified it to follow your instructions ?

 dwnoon@os2bbs.com

I poll that mailbox about 4 or 5 times a week.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.24.1
 * Origin: The man who broke the bank at Monte Carlo (2:257/609.5)

+----------------------------------------------------------------------------+

+============================================================================+
