Information Systems:InfoNet Overview - Revision history

Norwinu at 20:18, 22 June 2016

2016-06-22T20:18:20Z

New page

This was written in WebSmart PML and html, instead of RPG and DDS. Screen design is much easier in html - you don’t have to count field lengths and screen positions; the browser will dynamically just make everything fit.

The first programs in InfoNet were item and partner maintenance. There is just one program for each, instead of the previous dozens in both base ASW and the extensions. Because you can have a very long page in html (unlike the 24 row green screen), in maintenance all data fields can be keyed and validated at the same time.

We then started using it for inquiry programs. RPG inquiry programs in ASW and most of the extensions use SET and READ commands, then test to see if each record fits the search criteria. This was fine in the beginning, but now we have transaction files with record counts in the tens of millions. We had two options – rewrite these programs to use SQL instead, or write them in WebSmart – also using SQL. (For an explanation of why SQL is faster, see [[SQL|‘SQL – Structured Query Language’]].) We realized that development would be faster and easier in WebSmart, the resulting programs would be easier for the users, and the browser based screens would look better and be able to show much more information. (Instead of being restricted to 24 rows of 80 characters, the display is only restricted by how small the characters the user could read – which on a large display is a lot.)

Then we started thinking about replacing InfoManger, our business intelligence package. (It was expensive, inflexible, slow, and support was almost non-existent. See [[WebSmart History]] for details.) Again, because the WebSmart programs are all using SQL, the user can select from a broad range of select, sort, and summary options, and the optimizer finds the fast access path.

[[Category: Infonet]]

Sheilav at 23:00, 30 October 2015

2015-10-30T23:00:09Z

Sheilav at 17:08, 30 October 2015

2015-10-30T17:08:05Z

Sheilav at 17:06, 30 October 2015

2015-10-30T17:06:28Z

Sheilav at 17:02, 30 October 2015

2015-10-30T17:02:27Z

172.30.20.117: Created page with "This was written in WebSmart PML and html, instead of RPG and DDS. Screen design is much easier in html - you don’t have to count field lengths and screen positions; the br..."

2015-10-21T00:02:42Z

Created page with "This was written in WebSmart PML and html, instead of RPG and DDS. Screen design is much easier in html - you don’t have to count field lengths and screen positions; the br..."

New page

This was written in WebSmart PML and html, instead of RPG and DDS. Screen design is much easier in html - you don’t have to count field lengths and screen positions; the browser will dynamically just make everything fit.

The first programs in InfoNet were item and partner maintenance. There is just one program for each, instead of the previous dozens in both base ASW and the extensions. Because you can have a very long page in html (unlike the 24 row green screen), in maintenance all data fields can be keyed and validated at the same time.

We then started using it for inquiry programs. RPG inquiry programs in ASW and most of the extensions use SET and READ commands, then test to see if each record fits the search criteria. This was fine in the beginning, but now we have transaction files with record counts in the tens of millions. We had two options – rewrite these programs to use SQL instead, or write them in WebSmart – also using SQL. (For an explanation of why SQL is faster, see ‘SQL – Structured Query Language’ in the ‘Programming’ section of this manual.) We realized that development would be faster and easier in WebSmart, the resulting programs would be easier for the users, and the browser based screens would look better and be able to show much more information. (Instead of being restricted to 24 rows of 80 characters, the display is only restricted by how small the characters the user could read – which on a large display is a lot.)

Then we started thinking about replacing InfoManger, our business intelligence package. (It was expensive, inflexible, slow, and support was almost non-existent. See the WebSmart / History section above for details.) Again, because the WebSmart programs are all using SQL, the user can select from a broad range of select, sort, and summary options, and the optimizer finds the fast access path.

← Older revision		Revision as of 17:08, 30 October 2015
Line 5:		Line 5:
	We then started using it for inquiry programs. RPG inquiry programs in ASW and most of the extensions use SET and READ commands, then test to see if each record fits the search criteria. This was fine in the beginning, but now we have transaction files with record counts in the tens of millions. We had two options – rewrite these programs to use SQL instead, or write them in WebSmart – also using SQL. (For an explanation of why SQL is faster, see [[Utilities#SQL\|‘SQL – Structured Query Language’]].) We realized that development would be faster and easier in WebSmart, the resulting programs would be easier for the users, and the browser based screens would look better and be able to show much more information. (Instead of being restricted to 24 rows of 80 characters, the display is only restricted by how small the characters the user could read – which on a large display is a lot.)		We then started using it for inquiry programs. RPG inquiry programs in ASW and most of the extensions use SET and READ commands, then test to see if each record fits the search criteria. This was fine in the beginning, but now we have transaction files with record counts in the tens of millions. We had two options – rewrite these programs to use SQL instead, or write them in WebSmart – also using SQL. (For an explanation of why SQL is faster, see [[Utilities#SQL\|‘SQL – Structured Query Language’]].) We realized that development would be faster and easier in WebSmart, the resulting programs would be easier for the users, and the browser based screens would look better and be able to show much more information. (Instead of being restricted to 24 rows of 80 characters, the display is only restricted by how small the characters the user could read – which on a large display is a lot.)

−	Then we started thinking about replacing InfoManger, our business intelligence package. (It was expensive, inflexible, slow, and support was almost non-existent. See ~~the~~ WebSmart / History ~~section above~~ for details.) Again, because the WebSmart programs are all using SQL, the user can select from a broad range of select, sort, and summary options, and the optimizer finds the fast access path.	+	Then we started thinking about replacing InfoManger, our business intelligence package. (It was expensive, inflexible, slow, and support was almost non-existent. See [[WebSmart History]] for details.) Again, because the WebSmart programs are all using SQL, the user can select from a broad range of select, sort, and summary options, and the optimizer finds the fast access path.

@@ Line 3: / Line 3: @@
 The first programs in InfoNet were item and partner maintenance.  There is just one program for each, instead of the previous dozens in both base ASW and the extensions.  Because you can have a very long page in html (unlike the 24 row green screen), in maintenance all data fields can be keyed and validated at the same time.
-We then started using it for inquiry programs.  RPG inquiry programs in ASW and most of the extensions use SET and READ commands, then test to see if each record fits the search criteria.  This was fine in the beginning, but now we have transaction files with record counts in the tens of millions. We had two options – rewrite these programs to use SQL instead, or write them in WebSmart – also using SQL.  (For an explanation of why SQL is faster, see [[Utilities#SQL|‘SQL – Structured Query Language’]] in the ‘Programming’ section of this manual.)   We realized that development would be faster and easier in WebSmart, the resulting programs would be easier for the users, and the browser based screens would look better and be able to show much more information.  (Instead of being restricted to 24 rows of 80 characters, the display is only restricted by how small the characters the user could read – which on a large display is a lot.)
+We then started using it for inquiry programs.  RPG inquiry programs in ASW and most of the extensions use SET and READ commands, then test to see if each record fits the search criteria.  This was fine in the beginning, but now we have transaction files with record counts in the tens of millions. We had two options – rewrite these programs to use SQL instead, or write them in WebSmart – also using SQL.  (For an explanation of why SQL is faster, see [[Utilities#SQL|‘SQL – Structured Query Language’]].)   We realized that development would be faster and easier in WebSmart, the resulting programs would be easier for the users, and the browser based screens would look better and be able to show much more information.  (Instead of being restricted to 24 rows of 80 characters, the display is only restricted by how small the characters the user could read – which on a large display is a lot.)
 Then we started thinking about replacing InfoManger, our business intelligence package.  (It was expensive, inflexible, slow, and support was almost non-existent.  See the WebSmart / History section above for details.)  Again, because the WebSmart programs are all using SQL, the user can select from a broad range of select, sort, and summary options, and the optimizer finds the fast access path.