Frequently Asked Questions.
SilverDev is a complete system for graphic development using RPG ILE. It includes a TCP/IP communication server, a "rich client" for launching applications and development tools (graphic window design, service programs for RPG programming, application and job management tools, etc.).
SilverDev enables the creation and running of applications that "look and feel" like Windows, without the complexity of the Client/Server system. All the objects created during application development are stored on the IBM i, thereby avoiding deployment problems. The applications are immediately available to users, in the same way as 5250 developments.
The programs are entirely run on the IBM i, guaranteeing better stability and easier maintenance The use of RPG for development means there is no new language to learn for the new product and the first graphic applications can be created very quickly.
No, SilverDev uses its own TCP/IP communication server and requires no other servers like Apache, WebSphere AS, etc.
Yes, SilverDev uses TCP/IP, The only specificity is that in its basic configuration, SilverDev uses port 7003, which is not always open in protective systems (firewall, routers, etc.). However, it is simple to either modify the port used by SilverDev upon startup (StrSvd) or to open this port on the firewall, router, etc.
Silverdev has powerful built-in cache and optimization / compression functions for the frames exchanged. The bandwidth used is therefore similar or less than that of the 5250, for similar processing
It can be used very simply and remarkably efficiently (far better than web pages) for remote sites (branch offices, subsidiaries, etc.).
Yes! SilverDev interface is developed in native Windows. So, applications are automatically available on a Windows 8 Pro device like on a PC workstation, without compromising on performance.
No, the programs written for SilverDev use the graphic interface directly.
NO, provided you have a TCP/IP network connecting the IBM i to the client workstations (PCs) and enough disk space to install the product (just 75MB!), which is usually the case!
The right to use the SilverDev license is invoiced per IBM i system, the price varying according to the billing group (P05, P10, etc.). With one SilverDev license on one IBM i, you can use the product for as many users and developers as you want! If you need extra licenses (if you have several IBM i systems), a very attractive multiple license pricing policy applies. Contact our services for more details.
The usual skills of an RPG developer on IBM i are sufficient. The applications written for SilverDev are very similar to those written for the 5250, but the programs are in RPG IV ILE. Knowledge of Windows development tools (VB, Access, Delphi, etc.) would be an advantage, but is not necessary.
The SilverDev training course covers all aspects of graphic interface design using components, properties and events.
SilverDev applications work in "batch jobs", so anything that can be done in these jobs can be done in SilverDev. It is therefore possible to re-use the entire DB, programs in ILE or otherwise, data area, as well as adding other jobs. Only programs that use screens (DSPF or PNLGRP) cannot be used directly. They will have to be rewritten, although large amounts of the original code can be re-used (controls, DB access, calculations, etc.)
YES, it is quicker to develop using SilverDev than traditional 5250 because of the event-driven programming. The developer has less to implement to manage the interface. The 5250 requires the programr to write the code (instructions) to manage the interface events (function keys, etc.), while SilverDev takes care of such aspects automatically.
SilverDev enables working on two levels: a basic level rather like 5250 development or a higher level, using the built-in generator to improve productivity.
The use of RPG IV as the programming language also enables rapid development since some parts of previously written code (F15+ Copy in PDM SEU, etc.) can be re-used.
An RPG program is a SilverDev program simply because of its use of the functions provided by a program service (SDSRVPGM). The principle is exactly the same as for IBM APIs that can be used in ILE via program services.
Yes, and this is certainly one of the most innovative aspects of SilverDev. Programming in SilverDev makes full use of the principles of event-driven programming usually reserved for PC tools. This is so true that it can be somewhat disturbing at first for an IBM i programr, accustomed to batch programming. Indeed, in traditional IBM i programming, when an interactive program (with a screen file) calls another interactive program (with its own screen file), execution is suspended until execution of the called program has finished.
Event-driven programming, i.e. with SilverDev, works differently: the two programs are active at the same time, so the windows of both programs react to the user’s events (although this can be blocked by the programr). The flexibility and vastness of the interface really are those of a traditional graphic Windows interface, unlike existing revamping tools which are bound by the limits of the underlying 5250 interface.
When you create a graphic interface (forms) with SilverDev, you are indicating the events to which you want to program to react. As soon as the form is displayed, your program "goes to sleep" (zero resource consumption). It is only when the user triggers an event (mouse click, function key, timer, etc.), that the client part of SilverDev on the PC informs the SilverDev server on the IBM i via TCP/IP. This launches execution of the procedure defined by your program to manage this event. At the end of the procedure, control is returned automatically to the form on the PC to wait for another event.
No, although it is difficult to compare two such different things. Some functions may require more resources, but this is largely compensated by the fact that use of a more sophisticated interface than the 5250 requires less processing in the programs on the IBM i, resulting in more control on the interface side, fewer format changes, substantially lighter kinematics (thanks to the event-driven aspect) managed by the program, etc. It is obvious that requesting display of an image, for example, requires resources (minimal) to access the stream file on the IFS, then to transfer it to the client workstation, but this cannot be compared to a 5250 that cannot handle images. If we compare it with revamping tools, resource consumption is significantly less, since such tools cumulate their own consumption with that of the 5250 application.
Furthermore, and unlike web-based systems (http), the principles of the SilverDev interface are similar to those of the 5250. The interface (forms) is compiled for high speed transmission and execution. Then, only property modifications and event triggers are passed between the client workstation and the program on the IBM i, thereby keeping network and processor resources to a minimum.
A number of functions are processed by the components on the client workstation, thus reducing the processing carried out by the server (e.g. sorting of sub-file columns).
Integrated cache function and compression (as well as various optimizations) reduce the flows exchanged by about 80%. The result is a volume of exchanged data that is similar to or even less than that of the 5250.
Obviously any product as innovative as SilverDev is bound to provoke questions and even doubt. First of all, SilverDev is simple because it was designed to be simple. Our constant objective was to make a development tool that would offer productivity at least equivalent to that of traditional development (for management applications).
SilverDev is truly simple because it uses the best of two worlds: Windows and IBM i. The user-friendliness of the graphic interface under Windows makes it simple, and even fun, to design graphic interfaces.
The efficiency and management orientation of RPG and the IBM i DB, make programming simple, stable, effective and highly productive.
There are many reasons for this.
From a technical point of view, a certain number of conditions had to be fulfilled: the possibility of rapid, dynamic creation on a PC, the generalization of networks (LAN), a fast, stable and widespread communication layer (which is now the case with TCP/IP), and most importantly, a programming language for the AS that enables the management of events (which is the case with RPG IV ILE).
It is also likely that a major blockage was due to psychological factors: even today, it is commonly believed that "IBM i does not enable simple development of graphic applications; it cannot be possible, otherwise we would have heard about it!". Sometimes, it is enough to take a step back from the "reference framework" and reassemble the pieces of the puzzle. Indeed, without giving away any secrets, SilverDev uses no new or complex technology; it is merely a clever assembly of several techniques and ideas that form a major innovation.
There may even be a "psycho-commercial" aspect based on the sacred principle of "why make it simple when we can make it complicated?"
... particularly if we can sell complicated... and at a higher price!
Not quite. SilverDev has been purposefully oriented towards the development of management applications, which is the basis of IBM i design.
Therefore, certain graphic component functions have been blocked, firstly to simplify understanding and use of the product and secondly to avoid deteriorating performance by using functions that demand a lot of resources and add little to management applications.
So SilverDev is not made for highly interactive and graphic applications, like arcade games! Then again, that was not what we set out to do. However, the underlying technologies implemented will enable us to open up more of these locked functions in the future, as hardware and networks become more powerful.
Conversely, the concepts of SilverDev make things that are complex in PC programming easy and stable, simply because the programs are on the IBM i.
Like all communication server jobs on the IBM i (http, odbc, etc.), the job names are generic and it is often difficult to identify one specific job. However, SilverDev has an IBM i command, WRKSDJOB, which displays the SilverDev jobs associated with the real (current) user, the application launch command, etc. This makes the maintenance of SilverDev applications easier (job viewing and management, job maintenance launch, etc.).
SilverDev programs work in batch mode, so you have to start by placing the job in question in maintenance mode using the STRSRVJOB command. To help developers find the right job, SilverDev’s WRKSDJOB command displays and manages SilverDev jobs. Then, you just use the usual debugging commands (STRDBG, STRISDB, etc.).
Yes, SilverDev programs run in batch mode, so they do not need any interactive CPW power, which enables substantial savings.
Of course. The graphic interface is developed via the SilverDev server fwhich works in batch mode. It is possible to write RPG IV programs without SEU, using the built-in editor or tools by IBM (WDSC/RDI, Eclipse) or other suppliers. The server itself is managed via iSeries Navigator.
The client part of SilverDev installed on each user workstation includes a program called "MyDesk" which is a graphic "virtual desktop" for SilverDev applications. This virtual desktop, like the Windows desktop, contains icons that represent the applications, which can be run by double-clicking them. The applications can also be organized in folders and sub-folders.
The information from this virtual desktop (MyDesk) is not stored on the client workstation, but on the IBM i. When a user logs on with his/her login information on another workstation, the same information will be available as on his/her own workstation - exactly like passive terminals.
Furthermore, the applications displayed on the virtual desktop depend on the user’s access rights.
No, not necessarily. The virtual desktop must be installed on the client workstation to enable configuration of the connection information, but links can be created on the Windows desktop to SilverDev applications. The user then simply has to click these icons on his/her Windows desktop to run the SilverDev application. In this case, the user can forget that the application is running on the IBM i.
SilverDev includes print components that enable easy creation of reports comprising text, images or graphs. The content is controlled by the RPG program. Page header/footers and groups (breaks) are managed far more easily than with traditional RPG! The report is sent directly to a printer from the user’s workstation.
This new function is included in the SilverDev product at no extra cost.
Yes. The ADO component enables access to any BD with a ADO/OLE DB driver. This means all the operations authorized on the database in SQL are available via your RPG IV programs in SilverDev.
You can therefore query the database (DQL: SELECT), modify its content (DML: UPDATE, INSERT, DELETE), modify its structure (DDL: CREATE, ALTER, DROP, etc.) and call stored procedures, as well as accessing all the database management and maintenance operations available via SQL.