Re: FTP RCMD Date Weirdness -- MIDRANGE-L

Is it possible that under V4R3 your FTP job was ending between client
accesses and now it doesn't time out any more? If the host job used to close
down, you would have been getting a new job, thus a new date, when it was
accessed again.

Chris Rehm
javadisciple@earthlink.net
If you believe that the best technology wins the
marketplace, you haven't been paying attention.


----- Original Message -----
From: Nathan Simpson
To: MIDRANGE-L@midrange.com
Sent: Thursday, July 19, 2001 10:13 PM
Subject: RE: FTP RCMD Date Weirdness


I believe everything you say, I really do, but how come this has only popped
up since installing V4R5?

The IBM guy says it has something to do  with newer TCP/IP in V4R5 from
where we came i.e.. V4R3.

Nathan
-----Original Message-----
From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On
Behalf Of Jim Franz
Sent: Friday, 20 July 2001 09:30
To: MIDRANGE-L@midrange.com
Subject: Re: FTP RCMD Date Weirdness


Since 1988 (first 400) and back to 80 or 81 first '38) a job date is always
the date the job started, never truly current date. If as in the case of a
server job, where some jobs may spawn or start other jobs, every "job"
starts with a "job date". This is not a bug. I have had QZSCSRVR jobs in
V3.7 that did the same thing. If you need the real-time date in a cl-p,
rtvsysval qdate. In rpg, use the TIME opcode. This is no different than you
starting a job at 11:59pm and checking the date at 12:15am. RTVJOBA in clp
or UDATE in RPG has the date the job started. There is nothing magical about
IBM's server jobs. This is like tinkering with laws of nature & gravity -
this is the way it works. It's not broken.
jim franz
----- Original Message -----
From: Nathan Simpson
To: MIDRANGE-L@midrange.com
Sent: Thursday, July 19, 2001 8:15 PM
Subject: RE: FTP RCMD Date Weirdness


We are having the same problem with RMTCMD's run from an NT box.

The jobs run under QUSER.

In our case the date that the job uses is the day the QZSCSRVR job started.
IE last IPL.

We have placed a call with IBM. This has on;y started since we installed
V4R5.

Nathan
-----Original Message-----
From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On
Behalf Of Condon, Mike, /m1c
Sent: Thursday, 19 July 2001 23:41
To: 'MIDRANGE-L@midrange.com'
Subject: FW: FTP RCMD Date Weirdness


I got this message from a coworker. Any idea why ftp rcmd executed programs
would be getting an incorrect date, or if there is any workaround?
-----Original Message-----


Here's a weird one for you...

 Mr. Pink has noticed that the picking slip confirm date stored in Gal
appears to be a day behind sometimes.   I checked out the program (RRU12)
that stores the date in CS from the manifest upload and it is just moving
*DATE into STCNF.  This program is run every half hour and is run from an
FTP session using RCMD.

Mr. Black and I also had noticed this in something else when he was here.
It appears that sometimes yesterday's date is returned for *DATE when run
from an FTP RCMD.   To test this, I wrote a program JKJ/QSRC.TCPDATE to
output the date from *DATE.  Last night I ran it via FTP RCMD and it
reported the correct date and time.   However, this morning when I ran it
via FTP RCMD it still reported yesterday's date.  The results of this are in
my spool files.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---