It's dumb question time...is FOCUS relational or hierarchical? My boss is asking and I could not tell him a definite answer. His other question/statement was - if someone has experience with SQL, can that person then program in FOCUS?

Also, for whoever answers, what do you think your biggest issues have been with using FOCUS on a mainframe, and if willing to answer, how did you overcome those issues?

Thanks so much...looking forward to your replies!

This message has been edited. Last edited by: webmeister,

It's based primarily on hierarchical data model. If a person has SQL experience does not mean he/she can code in FOCUS. FOCUS is different from most language in that it is a 4GL language. People coming from OOP programming or scripting does need some time in getting used to the 4GL model. Sorry, no experience with mainframe. I stick with windows and Unix.

Sayed

The standard FOCUS database is hierarchical. There IS a version available that is relational. The FOCUS language is 4GL, so it's pretty easy to read and understand. Best way for me was to look at samples and already-written pieces of code, see what they do, copy and paste and then add new things I learned as needed. If you have SQL experience, you are familiar with a lot of the concepts of WF reporting like joins, selection, masking/wildcard, etc. so that knowledge goes a long way for FOCUS, but the language itself is different. One of the great things about FOCUS is that if you prefer to stay with SQL, FOCUS allows you to use SQL code or even SQL stored procedures to get what you need until you get a deeper knowledge of the language.

IMO is SQL knowledge not the most important part.
SQL is a database language, and something for the IT department. Webfocus is a reporting tool.
I would never recommend reporting to be done by the IT department. It's something for people with business knowledge. SQL just gets the data out of the database.
With WebFocus (or to be honest also with some other tools) you converts data to a higher level.

Even "standard" FOCUS Data bases can be relational. A long time ago, I was site coordinator for five thousand FOCUS users. When you are in this type of position you see many things, much of which should not exist.

I was asked to help understand an application, developed by someone who left. All the FOCUS data bases where single segment with indexed fields. Each of the data bases contained lots of data, and indexed fields increased the size even more. The application used multiple joins to create reporting structures as need. The whole thing met most Cobb & Dates definition of a relational model. If fell short on the requirement for meta-data storage. But it functioned perfectly as a relational DB.

BTW: making it hierarchal greatly improved response time.

Webmeister,

To add something to the above. You have to differentiate between the FOCUS file system and the FOCUS language.

The file system is "shared hierarchy". Each FOCUS file can support a hierarchy. The indexes provide the relational JOIN capabilities. This allows, often, the best of 2 worlds.

As with Jim, when "data warehouse" was not a buzz word, our customers used to have a set of files from which to report. By building these files with reporting in mind, one could achieve excellent reponse times. One of our customers has had his legacy data warehouse for the last 20 years. He tells me that his users extract some 250,000 reports a year, most of them using self-service applications.

Concerning the language, a programmer who knows SQL should be familiar with the concept of "set processing" where one declares what one wants and not how it should be done, as with 3GL langauges. Nonetheless, SQL does not provide, by a mile, the richness of FOCUS.

As for the issues, the important ones are personal: many people would not make the effort to learn FOCUS (that means, among other things, reading the manual... many times...) and also some have preconceived ideas which are hard to discard.

I hope that your organization can benefit from the enormous gains in productivity attainable when using FOCUS and WebFOCUS.

quote:

Originally posted by FrankDutch:
IMO is SQL knowledge not the most important part.
SQL is a database language, and something for the IT department. Webfocus is a reporting tool.
I would never recommend reporting to be done by the IT department. It's something for people with business knowledge. SQL just gets the data out of the database.
With WebFocus (or to be honest also with some other tools) you converts data to a higher level.

i don't agree, in all my jobs ive been in the IT department and have been providing business information. the knowledge of business processes probably as crucial as the coding but no more or less so...

most non-techies can move a few field columns around and introduce logic to get to the data they need but its the knowledge of database design, data standards and formats, data retrieval methods, system rollouts, non-language inherent functions such as office macros or cmd commands that separates a business expert from a business information expert- the latter understanding the medium of data delivery that the former doesn't...

could be different in other companies/countries but ive always sat in the IT dept

A FOCUS Database can be both, depends on how you use it.

If you have single segment FOCUS files that have foreign keys, then its relational.

If you have multiple segments in a FOCUS file then its hierarchical. This, of course, could still have foreign keys and be relational as well. A hierarchical FOCUS file is closer to a View, multiple tables shown as one file, except that the FOCUS file can have multiple paths.

quote:

if someone has experience with SQL, can that person then program in FOCUS?

Since you have had enough answers on the FOCUS DB, I'll only address some of your other questions. You can use SQL passthrus in FOCUS, so if you are wanting to use that to extract the data you can. You have much more control for formatting and display with FOCUS than with SQL and often there is not a significant time savings using SQL to do the data extraction. Focus will be easier to learn by somebody with any other programming experience, but it is user friendly and frequently used by total novices.

A SQL programmer *could* learn it like any other language - whether they *want* to is another story. I think a lot of SQL programmers use the Query Builder (nothing wrong with that) and when you show them lines and lines of code they kind of freak out. You can do some pretty complex things with FOCUS and Dialogue Manager which is far beyond SQL and I can see how someone could get intimidated.

For FOCUS on the mainframe, the VM and MVS are certainly different environments, but the good thing is that almost all your non-systems environment code can be pretty easily ported between the two environments.

I don't recall too many headaces on TSO mainframe based on my fuzzy memory. Maybe a few "gotchas" were running out of DASD space, 80 character limit for programs in partitioned datasets (could be totally wrong on that - it's been quite a number of years), low values [hex(00) vs hex(40)], I think the Screen Painter thing had a few funky quirks but I can't remember specifically.

IMO, FOCUS database offer the best of both. One other cool feature is when you have multi-segment FOCUS files, you can access the data by going into any segment, that is, you don't have to access from top-down. You can access from the bottom or middle. Does IBI still teach Internals. The most valuable class I ever took was their TOP GUN class. A week long of TABLE, MODIFY and database structure internals.

Wow! Thank you ALL for replying and letting me know what you think. I too enjoy FOCUS programming and think I have the addeded advantage of knowing SQL work and also knowing how to program in several other languages (COBOL, VB, SSAS, etc). I wanted to get the opinions of others, to be able to better answer my bosses questions, and it looks like you all helped very much.

Thanks again to all who answered, and please.... keep the replies coming.

Ironically SQL has moved towards wf hierachical model over the years in that the LEFT JOIN has to be carried out in the order specified. Code every join as a left outer and you have the equivalent to reporting from a hierarchy!