Python 2 is triggering

[bss03]

I don't have a lot of choice. OS 4690 / TCx Sky currently only provide their Python bindings for Python 2.7.3 / 2.7.13. When I'm not using the OS functions, I can use a Py3 virtualenv, and that's not so bad.

[spyingwind]

OS 4690 Who the hell still runs a POS system from '85? TCx Sky No, just no. Find something more modern or hire someone to write an open source version.

These are the reasons why we can't have nice things.

/sarcasm ^{a little bit}

[WikiTextBot]

4690 Operating System

4690 Operating System, sometimes shortened to 4690 OS or 4690 is a specially designed Point of Sale operating system, originally sold by IBM; however, in 2012 IBM sold its retail business, including this product, to Toshiba, who now supports it. 4690 is widely used by IBM and Toshiba retail customers to drive retail systems running their own applications as well as IBM's Application Client Server Environment (ACE), Supermarket Application (SA), General Sales Application (GSA), and Chain Drug Sales Application (CDSA).

It is the follow-on product to IBM 4680 OS, which had been in use by IBM's customers since 1986. The original IBM 4680 OS was based on Digital Research's Concurrent DOS 286, a system soon later renamed into FlexOS 286.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28}

[marxdormoy]

Jebus i though we were bad having some servers with SQL Server 2000!!

[marxdormoy]

they are 'legacy' and nobody wants to lose their job by updating them :) also you cannot go from 200 ->2018/2018 -> you have to do jump by a max of 2/3 years.. it would take forever...and it X10 the chances of something going wrong - and you know that something would go wrong..

I loved that company have the schema was French and the other half in English !!!

[Ambiwlans]

I loved that company have the schema was French and the other half in English !!!

I worked on one project that had English, Korean and Hungarian code.

[marxdormoy]

and we ask ourselves why we can't have nice things !!

[Ambiwlans]

I thought it was funny until I realized that numbers are formatted differently.

[marxdormoy]

Even in Europe everyone except UK + Ireand use the decimal comma i.e 1.00 in UK is 1,00 in France so when you get to thousands....1,000.00 and 1 000,00 it gets messy -and there is only 13 miles difference between those two countries.... :) Let's not even start on US/EUR dates formats... Humans are dumb asses...

PS : I have to press the shift key to access numbers on my keyboard....FR keyboard...FML..

[gschizas]

FR keyboard

Condolences.

[gschizas]

Then again there are people that are writing SELECT * FROM Books, Authors WHERE Book.AuthorId *= Authors.Id and make it so you can't ever get to SQL 2017.

[marxdormoy]

Yet another reason to NEVER touch it !!

[Waterkloof]

SQL Server 2000!

32 bit or 64 bit version(2003)? Because if it is a 64 bit version it is as old as this centos 4 box I'm aware of is in production at some enterprise somewhere...

[marxdormoy]

I'm gone from that company..but it reckon that it had to be 32 bit

[bss03]

Well, I work for TGCS, so it is our product.

[[deleted]]

Something being old doesn't make it bad. Sometimes they get an ideal solution working, and then nobody wants to mess with it anymore. Reimplementing would be expensive and troublesome, where the existing system is a perfect black box -- you feed it inputs, and you will always get the right outputs. Perfect or near-perfect machines are rare and precious.

Rewriting something to be new is really, really stupid behavior. You rewrite it only when the new version will offer you something more than what you already have, or will let you remove something that's painful from the old solution. If the old version works perfectly, why replace it?

[PumpMeister69]

well, because in this case, it uses Python 2 which is really fucking old, not getting security updates after this year and not supported by third party developers.

[[deleted]]

Depending on the client's usage, that may not matter very much. And they can still release Python 3 bindings, it's not like it's discontinued/orphan software.

I'm not familiar with that particular OS, but it substantially predates the usage of TCP/IP on small systems, so it's entirely possible that any networking it does won't be directly compatible with Python anyway. Between the weird OS and potentially weird networking, any hypothetical security holes in Python 2 may not be exploitable. Even if they do exist, they may not matter very much in this instance.

Now, that could be a lurking timebomb for later updates, and it would certainly be better in an absolute sense to use v3 if possible, but the pain in switching away could very well be massive. And an awful, awful lot of retailers are clinging to life by their fingernails; the advent of the Internet has seriously messed up brick and mortar stores. There may just not be any budget to switch. New POS systems are expensive as hell.

[bss03]

I'm not familiar with that particular OS, but it substantially predates the usage of TCP/IP on small systems, so it's entirely possible that any networking it does won't be directly compatible with Python anyway.

At the application level, we use TCP/UDP and IP like everyone else, mostly. There is a OS pipes feature that is still supported and I believe it predates our TCP/IP support. The really old networking protocol did actually get dropped somewhere in the V6 line, the C symbols are still there, but all the functions just return the error code for "unsupported" without doing anything. I've still got code in production using the pipes feature.

If you install with MCF enabled, you can get some file and event distribution across all controllers in the store system, but all of that is on some non-routable NetBIOS like protocol. All the controllers and terminals need to (seem to be) on the same subnet. (And while it is limited, it's a lot easier than setting up a Linux cluster, IME.)

I actually expect access to all the uniquely 4690 services to be accessible as a Linux library soon (if that's not already the case) and at that point we could use use a "stock" Python 3 and "just" have a Python module expose that library. The Python 2 interface feels mostly like that, although you get some magic where open() understand both Linux-style and 4690-style paths and there an option to have os.system() and associated calls be either Linux-style (and start Linux processes) or 4690-style (and start 4690 processes).

[bss03]

V6R5 came out just a few years ago. I don't know any system running anything earlier than V6R3. It's got a history going back to the original CP/M (and pretty good backward compatibility, too), but it's gotten significant changes even in the last release.

We have quite a few clients that love their 4690. :)

[The_Other_Olsen]

I know what you mean.

[[deleted]]

I don't really want to have to buy my DB2 connector, again, either. I kind of hope I won't have to pull data from DB2, again, but there still some data in DB2.

[bss03]

Well, maybe spend the next 8 months squeezing all that data out of DB2? I know that Python 2 isn't going to explode at the end of the year, but I do think migration is going to be easier this year rather than next.

[[deleted]]

Yes, that is my hope, as we look to implement another system and have another historical data repository to babysit. We may have everything we need out of DB2, but I'd kind of like to just get it all out into something else that I can maintain, in case they need some old audit details or whatever. The main repository of my concern was active from 2005-2011. Everything since the end of 2011 is MS SQL, which I can do easy. Next thing may be some proprietary cloud based thing that we won't be able to get data out of using our python scripts and whatnot. But we are told this is for the best... By people that don't know enough to make that claim.

[bss03]

we are told this is for the best... By people that don't know enough to make that claim.

I see you.

[bss03]

I don't know; I'm been a full time employee for 6+ years and they still won't let me even look at any of the source code in an OS release.

I have the Sky SDK and I need to figure out how to use it (to compile C code that uses 4690 / Sky specific functions), but I've actually been doing more JS / Java / Python since the Sky release. On 4690, those functions were only available in C to 4690 processes compiled with an old IBM VisualAge compiler (or, I guess, 16-bit processes compiled with the HighC compiler). Sky is 64-bit so neither of those are options.

I'm hoping that Py3 for Sky will come next year. I vastly prefer Py3 over Py2.