a particular question: is there a direct way to make an AS400 connection or do you have to go through PHP? I don't have to read data on DB2, but do the various commands (wrkactjob, wrksyssts, etc.). Thank you.... sorry for the English.
what I thought (maybe it can't be done) is this: in the app screen there are buttons, each button executes a command (wrkactjob, clroutq, etc.) and the answer occurs in another screen ... I didn't want to write commands directly like on 5250 or telnet
From your referral to typical "health checking" programs, like wrkactjob, and wrksyssts I guess your primary goal is to have an application running on your Android based phone to quickly check the status of a machine from wherever you are. Correct?
Have you considered how to get access to the machine's IP address when you're on the road and not connected to the local WiFi?
You can access this "performance data" through SQL — as John Y pointed out — and display it in whatever for is convenient on your mobile device. But I highly doubt Android provides ODBC infrastructure, even though you might manage to get the correct binary blobs (CPU wise) of the ODBC drivers from IBM botched into Android.
Otherwise you want to create a mechanism to scrape the screen for whatever is displayed, and translate that textual representation into UI elements provided by Flutter, if you want UI elements instead of textual output.
If you already have your doubts that you can't do telnet with Flutter, I think you'll have to learn a lot about Flutter as an SDK before even thinking about how to start developing an application. TCP/IP networking services are a function of the underlying OS and you'll have to go through all the Flutter abstraction layers to eventually be able to build a TCP session. With some luck, there is already code available to handle the telnet protocol peculiarities for you. Perhaps not, then you need to provide telnet negotiation and protocol yourself. This is documented in numerous RFCs. Use Google yourself.
Next point is: You need to establish translation routines for conversion of EBCDIC charset data into ASCII. Because Android is Linux based, you need to learn how to call libc routines like iconv() through Flutter, providing a C interface for charset conversion, including EBCDIC flavors as source/target.
Final point: You need to learn how to interpret the 5250 data stream, and translate the terminal emulator instructions into dynamically place Flutter UI elements at appropriate positions on screen. And of course you need to understand what to send back to IBM i to make it understand your request. The tn5250 data stream is also documented in publicly available RFCs.
There once was a facility called Workstation Gateway in the OS, but as I've found out, it has been removed in V5R2. This might have provided an easier means, because the 5250 data stream was converted on the fly to plain HTML.
Now it's your turn to decide if your goal is worth the apparent effort you're required to go through.
I am not sure what you mean by "direct". Do you mean doing your own socket programming? You could, but there are easier ways to connect.
The most obvious and straightforward choices are probably ODBC, JDBC, HTTP, and SSH.
ODBC and JDBC of course provide an SQL-based interface, and you can use that to issue commands (via the QCMDEXC procedure or scalar function) or access an increasingly comprehensive array of IBM i services.
If what you need still isn't available via SQL, or you simply don't like working in SQL, you could make use of the XMLSERVICE library, which provides its own programming interface "on top of" any of the connection types mentioned above. Despite all the instructions for building from source, normally this should already be installed on your IBM i. There are higher-level wrappers for XMLSERVICE in several programming languages (.NET, Node.js, PHP, Python, Ruby, and Swift), but as of this writing, not Dart. I am not familiar with Flutter, but I imagine you could use the JavaScript interop package to work with the Node.js wrapper.
Related
I was talking to a friend of mine who knows a lot about js and wasm.He told me the technology goes far beyond web, since it is basicly a way to run near native applications on devices without actually giving them access to the computer.
Which means that thrid party or untrusted code on a smartphone for instance cannot accidentally or intentional change other apps or parts of the system.
This seamed to me like the perfect conditions to build a plugin system for an application I am working on.
I asked him about it but he was unable to give me a clear answer.
So the question is, can I use webassembly outside of a webbrowser, with custom bindings to safely allow users to extend the functionality of my application (a special image viewer) without sacrificing too much speed? It seams it should work using libnode or something, but is there a problem I might run into?
I don't know how much you know about web assembly but it depends on what your plugins actually should do. If it basically handle Arrays and numeric data with not that match interacting with host applications then it might fit. But when you have heavy object handling then it will not fit at the moment. So for image processing it might be perfect match like it is used in some web examples. Also be aware that some web assembly targeting system or not suitable for none web targets as they generate also some javascript code to be used in browsers beside the generate wasm. Some wasm modules for example require that you call malloc and free for string handling other have functions like new and gc for the nearly the same.
I'm wondering if for simply communicating with a PLC, like reading and writing tags, do I need all of the other heavy lifting that comes with an OPC-UA server?
I've tried writing a simple server in Python that talks to the PLC, but I get denied when requesting information from the PLC.
The Controllogix PLC I'm attempting to communicate with uses Ethernet/IP to communicate, so why doesn't a simple server/client script work? What is required exactly to communicate with an Allen Bradley PLC or PLC's in general?
There is quite a bit required to communicate with a PLC.
Each vendor has a driver, there are firmware compatibility considerations. Different protocols to think about.
OPC-UA makes it a bit more generic, but OPC-UA still has a set of things to work around when setting up communications.
Most of the OPC products I've worked with, needs to have their security adjusted to allow anonymous communication. It's generally bad practice to do this. (A network intrusion would be able to read/write to your automation layer) There is certificate signing and some encryption business that needs to be turned off if you're looking for simple communication. (Again, not a good practice but ok for learning)
After all that you have to have a notion of how your PLC is set up on your OPC server, there are channels, devices, namespaces etc. You'll point the OPC client to some opc.tcp://:
If you got this far you're almost done, I'm assuming your OPC server is running and has tags configured at this point. You can use your OPC-UA API to do a read. It can return just the value, or you can get an object back with tag health, timestamp, and a bunch of other data. Depends on the implementation. After that you can do subscriptions, writes...whatever else you need.
TLDR: OPC server not required, but may be the easiest method. Turn off security. (But turn it back on before exposing your control layer to the net)
I am also a little late to this conversation. If you are interested in coding your own solutions and don't want to use any of the commercially available standards, AdvancedHMI is a "mostly" open source solution written in VB.NET which is 100% free and provides communications to many different PLCs including the ControlLogix platform. Since I see you are programming in Python you may also be interested to know that the project does work under Mono on the Linux OS. I have used it to write gateways between EthernetIP and ModbusTCP and to pull data serially from OEM devices and push this data to a CLX PLC.
The forum is full of many helpful hints and is very active and supported.
Just trying to give you another option. DDE, NetDDE, FastDDE, OPC, DCOM, Suitelink.... These are all good, but mostly a pay to play adventure. As a programmer, it seems ridiculous to have to pay such an excessive amount of money just to talk to my hardware, IMHO. Sorry for the rant. Have Fun!
Update - Just wanted to also suggest the following open source project written in python:
https://github.com/dmroeder/pylogix
I have used this to write small programs for communicating with CompactLogix and ControlLogix. (Even to/from a RaspberryPi!)
Depends on several factors, if you want something simple to program you can opt for Modbus/TCP I think some AB PLC supports it without extra hardware.
However if you want something with more security for example for industrial use then OPC UA would be better choice but the programming has a complexity far higher than Modbus, even using the libraries of OPC Foundation or others. There is the option of using a commercial or free (if any) OPC UA server to save work, then you will need to program the client side only.
With Ethernet/IP it should also be possible, but the problem is that there is no clear specification and even different AB models talk different Ethernet/IP dialect ! , it is also far more complex to program than Modbus.
I am a little late to this discussion, but there are a couple commercial tools that make this a bit easier. The one that comes to mind for me when you say you are using python is Cogent's data hub. It is certainly not the cheapest tool out there, but they have already done all of the heavy lifting for PLC/PC communications & security.
If trying to read CLX data using Python, there are several open source implementations that will save you a lot of work. Such as this:
https://github.com/dmroeder/pylogix
If you use .NET and Visual Studio, you can use AdvancedHMI
to be able to read and write OPC Tags to ControlLogix platform is done via its communication Driver RSLinx. RSLinx acts as an OPC Server, it will need to be configured to communicate with the PLC and run on a networked PC on the same LAN. Several flavours of RSLinx are available (for WAN/VLAN also) but essentially this is the communications driver you need to talk to AB PLC's
How could one interact with a locally long-running Common Lisp image, possibly daemonized, from the command line?
I know it is possible to run a Common Lisp function from a Terminal command prompt, I am also aware of this.
I would need to do a similar thing, but with a local, already long-running Common Lisp image, being able to poll available functions from the CLI or shell scripts.
Is there a way to do that from a CLI, for example calling a function from a bash script, and receiving back whatever the function returns?
I though one could, for example, create a primitive web service, perhaps using woo or Hunchentoot, calling functions and fetching returned values via curl or wget, but it feels a little convoluted.
Of course, that is one of the many features of Emacs' SLIME, but I would need to call functions just from the CLI, without invoking Emacs.
Is there perhaps a way to reach a swank backend, outside of SLIME?
If possible at all, what would be the lisp idiomatic way of doing that?
I would be grateful for any pointers.
Update
Additional note
Many years ago, I was intrigued by being able to telnet into a long-running LISP image (I believe in this case uppercasing the name should be fine). If I remember correctly, it was available at prompt.franz.com. An article, somehow connected: telnet for remote access to a running application
Telnet is of course quite unsafe, but the usefulness of being able to access the Lisp application(s) in that way, for whatever reason, cannot be overstated, at least to some people.
Some additional pointers, and thanks
I would like to thank Basile Starynkevitch for his elaborate and thorough answer, especially on the theoretical aspect. I was looking for a more practical direction, specially connected to Common Lisp. Still, his answer is very instructive.
I was all ready to start writing a local server, perhaps using one of the fine Common Lisp libraries, like:
usocket: Universal socket library for Common Lisp
iolib: Common Lisp I/O library
cl-aync: Asynchronous IO library for Common Lisp
But, thanks to Stanislav Kondratyev, I didn't have to. He pointed out an already existing solution that nicely answer my question, ScriptL: Shell scripting made Lisp-like
I tested it with success on Linux, FreeBSD and OS X, just make sure to install the thin wrapper over POSIX syscalls first. Among many features (see README), it allows exposition of just selected functions, security is properly handled, and it even supply a custom C client, which builds as part of the ASDF load operation, and supports a number of new features, such as I/O, in place of netcat.
You may find scriptl useful: http://quickdocs.org/scriptl/. However, it depends on iolib, which depends on some nonstandard C or C++ library, so building it is not quite straighforward.
It is indeed possible to communicate with a swank server if you familiarize yourself with the swank protocol, which seems to be underdocumented (see e. g. here: https://github.com/astine/swank-client/blob/master/swank-description.markdown). However, this exposes a TCP socket over a network, which could be unsafe. Once I tried that, too, but I was not satisfied with the IPC speed.
A while ago I wrote a rather naive SBCL-specific server that uses a local domain socket for communication, and a client in C. It's very raw, but you could take a look: https://github.com/quasus/lispserver. In particular, it supports interactive IO and exit codes. The server and the client form the core of a simple framework for deploying Unix style software. Feel free to borrow code and/or contact me for explanations, suggestions, etc.
It certainly is operating system specific, because you want some inter-process communication, and they are provided by the OS.
Let's assume you have a POSIX like OS, e.g. Linux.
Then you could set up a socket(7) or fifo(7) to which you send s-exprs to be evaluated. Of course you need to adapt the Common Lisp program to add such a REPL.
SBCL has some networking facilities, you could build on them.
Of course, you should understand first how IPC work on your OS. If it is Linux, you could read Advanced Linux Programming (it is centered on C programming, which is the low-level way of using OS services on POSIX, but you can adapt what you have learned to SBCL). And indeed, the Common Lisp standard might not have an official POSIX interface, so you need to dive into implementation specific details.
Perhaps you should learn more about BSD sockets. There are tons of tutorials on them. Then you could use TCP sockets (see tcp(7)) or Unix ones (see unix(7)). Advanced users could use the unsafe telnet command. Or you might make your software use SSL, or perhaps some libssh e.g. use ssh as their client.
You could decide and document that the protocol between user apps and your program is : send some-sexpr (on a documented socket) from user-app code to your server which is terminated by a double newline or by a form feed, and have your server eval it and send back the result or some error message. I did similar things in MELT and it is not a big deal. Be careful about buffering.
I guess that you assume that you have responsible and competent users (so don't open such a remote REPL to the wild Internet!). If you care about malicious or stupid use of a remote REPL, it is becoming complex.
Alternatively, make your server a web application (by using some HTTP server library inside it), and ask users to use their browser or some HTTP client program (curl) or library (libcurl) to interact with it.
I've recently decided to take on a pretty big software engineering project that will involve developing a client-server based application. My plan is to develop as many clients as possible: including native iPhone, Android and Blackberry Apps as well as a web-based app.
For my server I'm planning on using a VPS (possibly from slicehost.com) running a flavor of Linux with a MySQL database. My first question is what should be my strategy for clients to interface with the server. My ideas are:
HTTP-POST or GET based communication with a PHP script.
This is something I'm very familiar with - passing information to a PHP script from a form, working with it and returning output. I'm assuming I'd want to return output to clients as some sort of XML or JSON based string. I'm also assuming I'd want to create a well defined API for clients that want to interface with my server.
Socket based communication with either a PHP script, Java program, or C++ program
This I'm less familiar with. I've worked with basic tutorials on creating a script or simple application that creates a socket, listens for a connection and returns data. I'm assuming there is far less communication data-overhead with this method than an HTTP based method. My dream is for there to be A LOT of concurrent clients in use, all working with the server/database. I'm not sure if a simple HTTP/PHP script based communication design can scale effectively to meet the needs of many clients. Also, I may eventually want the capability of a Server-Push to clients triggered by various server events. I'm also unsure of what programming language is best suited for this. If efficiency is a big concern I'd imagine a PHP script might not be efficient enough?
Is there a commonly accepted way of doing this? For me this is an attempt to bridge a gap between some of my current skills. I have a lot of experience with PHP and interfacing with a MySQl database to serve dynamic web pages. I also have a lot of experience developing native iPhone applications (however none that have had any significant server-based communication). Also I've worked with Java/C++, and I've developed applications in both languages that have interfaced with MySQL.
I don't anticipate my clients sending/receiving a tremendous amount of data to/from a server. Something on par with a set of strings per a given client-side event.
Another question: Using a VPS - good idea? I obviously don't want to pay for a full-dedicated server (slicehost offers a VPS starting at ~ $20/month), and I'm assuming a VPS will be capable of meeting the requirements of a few initial clients. As more and more users begin to interface with my server, I'm assuming it will be possible to migrate to larger and larger 'slices' and possibly eventually moving to a full-dedicated server if necessary.
Thanks for the advice! :)
I'd say go with the simplicity of HTTP, at least until your needs outgrow its capabilities. (The more stateful your application needs to be, the less HTTP fits).
For low cost and scalability, you probably can't go wrong with a cloud like Rackspace's or Amazon's. But I'm just getting started with those, my servers have been VPSs from tektonic until now.
I have received a job at a hospital which still uses COBOL for all organizational work, the whole (now 20 Terabyte) database (Which was a homebrew in, guess what, COBOL) is filled with the data of every patient since the last 45 (or so) years.
So that was my story. Now to my question:
Currently, all sockets were (from what I've seen) implemented by COBOL programs writing their data into files. These files then were read out by C++ programs (That was an additional module added in the late 1980s) and using C++ sockets sent to the database.
Now this solution has stopped working as they are moving the database from COBOL to COBOL, yes - they didn't use MySQL or so - they implemented a new database - again in COBOL. I asked the guy that worked there before me (hes around 70 now) why the hell someone would do that and he told me that he is so good at COBOL that he doesn't want to write it in any other language.
So far so good now my question:
How can I implement socket connections in COBOL? I need to create an interface to the external COBOL database located at, for example, 192.168.1.23:283.
You need to give more information about your OS and compiler.
If you are on IBM z/OS with a Language Environment supported compiler, you can just call the EZASOCK functions from the z/OS communications services. The calls are well documented in their references and have good Cobol examples.
Other platforms will have other options.
In most cases, you can just "CALL" an external module written in whatever language you need, but that a DLL or a sharedLib or whatever.
Can you give some more detail about your environment?
Why don't you just write directly to the database from the Cobol program?
IBM mainframes has two sockets APIs that can be used form COBOL.
One for use inside a CICS programs (where there are special thread safety and envrinment considerations) and one for use in ordinary Batch or IMS programs.
The complete TCP/IP functionality is implemented and its reliable enough to handle Credit Card protocols to MVA standards ( I know 'cos Ive done it).
Most COBOL compiler will allow you to link and call in an object module or DLL. As Kati says I know I can help but need the additional information. I've done this previously from windows to DEC so i know it can be done.
Recall that Google is your FRIEND.
The answer will depend heavily on your execution environment.
IBM does claim to have a Sockets API callable from COBOL, as part of CICS for z/OS.
Micro Focus appears to have something.