Time & Attendence (Y2K)

[Chris Kelleher]

We are running Intermec time & attendence which goes to a DOS pc (which is not Y2K) and then upgrades to Symix. This machine in the middle needs to be replaced to become compliant. I believe it is currently running DOS lan workplace. What I need to know is what can I run on the new PC to replace the connection between Intermec and Symix.

I am new to Symix and I hope I am explaining this correctly. It seems to me like this would be a very common problem.

Running Symix 4.1R2 on Progress 8.3b07 on a Unix Box.

Any suggestions would be greatly appreciated.

Dave Siddons
dsiddons@envproduct.com

 

[Chris Kelleher]

The Y2K state of your PC is irrelevant to the function of Intermec store and forward. It is just writing a text file that the background data collection process is importing. Doesn't matter what the file date is 1/1/80. The other thing about Y2K compliance has to do with how non-compliant is the PC. I have a hodge podge of systems from 286's on up
and the only non-compliance I have found is that some systems cannot automatically roll-over past 12/31/99. However, if you re-boot the systems after that time and set the clock, it works fine from that point on. And again, in your case, what difference would it make.

The only thing you have to do for data collection to work is to put your Intermec file somewhere where your unix system can see it. When we were using Symix 3 running on an RS-6000, we used Novell NFS to mount a Novell volume on the unix system. Now that we are running Syteline 3.5 running on an NT machine, we map a Novell volume as a drive on the
NT database server.

We never used Symix 4 but I suspect the data collection part is pretty much the same. You would have to then edit your trak.sh file to tell
Symix where to look for the imtrans file. If you use the NFS route, you would also have to grant the unix system full rights to the directory where your imtrans file is.

Good luck.

 

[Chris Kelleher]

Around Symix4R7.09 they fix a hardcoded "19"+date in the import program ...
I think EDI import has the same "feature" ...
Try running strings on the .r's of find a kind soul with sources ... Small
thing to fix but better be aware of it for those on early Symix4.0 versions
(1996/97) ... Of course I would expect Symix4.1R2 to be corrected since it
was out in/around 98 ...

Eric

 

[Chris Kelleher]

Not an answer but another question. Am running dc on 4.0r.8.01 and when I
change to the year 2000 in testing mode I get a return date of 01/01/89. I
get this return from all my devices. I run 9154 collector, 9560 t&a, and
9512's. Any ideas? This is on a SCO box.

 

[Chris Kelleher]

We have the Intermec equipment and I checked with Intermec and there are
no updates to their hardware planned. It deals in 2 digit years and their stance

is it's up to your software vendor to deal with Y2K issues. It's not a problem
since
that is compatible with the way Symix works. Since they use the rolling 100
years,
the Intermec output is OK.

The Intermec 9154 controller is the where time is maintained for the Intermec
readers.
You can either run a terminal session directly to the controller by using
communications
software or by using the Symix command line stuff. I prefer to use the
communications
software because I know it getting changed properly.

 

[Chris Kelleher]

How would one go about doing that .. I am at a loss .. Symix Support is
looking at it currently but they started by saying it was an Intermec
problem. I don't care whose problem it is currently it is mine. Any help
would be appreciated.

 

[Chris Kelleher]

You might want to approach this from a different angle. The real question
with regards to Intermec store and forward is "Will Symix continue to support
this equipment and will they continue to accept 2 digit dates from them."
Intermec's
9154 Controllers and associated readers will never be Y2K compliant. As
long as Symix continues to use the rolling 100 years model, there should be no
problem with the Intermec hardware. Together, they are Y2K compliant.

 

[Chris Kelleher]

Using live system set clock up to 2350 12/31/99 let system roll over. As is
usual for the 9154, 9560 and 9512 you have to reprogram the controllers to
get the time to change. Did that and did a time and attendance transaction,
got date as 1/1/89, also tried some job labor transactions and received the
same date. To make sure I retried this same thing two more times with the
same result. When the system was reset to the 1999 date and the devices
reprogrammed everything was working correctly again.

 

[Chris Kelleher]

I just checked the date function on our spare 9154. I set the date to 99.12.31
@ 23.59 by connecting to the administrative port on the front. When the time
cranked over to 00:00, the date changed to 00.01.01. The bad date must be
coming from the PC and not from the Intermec 9154 controller.

Try another test. Set your PC to 12/31/2001 @ 23:59 and then update the
Intermec Controller and then wait until the rollover happens. Then check the
time on both the PC and the controller. Unless your PC is one of the very
unfortunate few, it will correctly display 01/01/2002. The controller should
work based on my test above.

Most older PC's cannot rollover automatically on 12/31/99 but after that, they
have no problem dealing with dates and rollovers for subsequent years.

If what I predict above is correct, the only thing you will have to do to keep
your
system working properly is to re-boot your data collection PC after midnight on
12/31/99. And there is no big rush. The controller is going to rollover without
any intervention. You just need to get the PC rebooted before you update the
time to the controller.

 

[Chris Kelleher]

Thanks for the information. Only one problem I do not have the data
collection coming from a PC but comes back to the system thorough a 3-COM
card. The Unix box bios is ok. All times are reported correctly, in both SCO
and Symix when I do the roll over.

 

[Chris Kelleher]

Since we also have a similar setup: The main question is can you set the
time to 00:01 01.01.00 on your 9154 ? It's possible that the rollover does
not work but setting the date manually does work ... Like the old PC BIOS
... I'll have to run my test again but when tested it (BTW we don't
broadcast time from SCO to the 9154) ...

What revision is your 9154 ? ours is 2.1 maybe that's the difference ...

Eric.

PS Worse come to worse you can easily use a Unix script to "plug" the year
id nothing else works ... Use sed to sub "89|" to "00|" if does not conflict
with other fields prior to the date ... That would be only a few line to add
to trak.sh . Of course activating the savtrans() function would not be a bad
idea while testing it ...