1. Sirius Update
SUG 2004
Gary Gregory

2. Agenda Welcome Some questions for the audience
schedule "tuning"
Some questions for the audience
ok to ditch 3480 drives?
documentation
Overview of newsworthy events
Brief Review of Recent Releases
Web Services/Service-Oriented Architecture — You Can Do It!
A look at our future direction

3. Welcome to Tenth Annual SUG
April 25 - April 29, 2004
Who would have thought
next year is twentieth anniversary of Sirius
Our first international User Group meeting outside of the Boston area
better weather (warmer, anyway)
change of scenery
More new attendees
More User presentations
More fun!

4. Schedule Tuning - Tuesday
SOAP, UDDI, SOA, BPM, MDA, UML – Bingo!
Gary Gregory
HTTP Client Programming with Janus Sockets and SOAP
George Walter
Break
Phillip Morris
Object-Oriented XML API
Dave Evans
Lunch
Janus SOAP Talks to Your End-Users
Alex Kodat
Managing Large Procedure Files
Tom Thoresen
Break
RJR
SOA at Centrelink
Daniel Yee - Centrelink
Java and Model 204: Web Serving or Application Development – It's Your Choice
Steve Nelson - CCA

5. Presenting Users - Thank You!
Ann MacEwan - Texas Youth Commission
Janus Web Server - Better Than Botox For Your 3270 Applications
Mon
Daniel Ascher - Marks and Spencer
Real-Time Inventory Management Using Model 204 with Microsoft Biztalk
Mon
Daniel Yee - Centrelink
SOA at Centrelink
Tue
Don Essick - Northrop Grumman
Developing an Enterprise Query Solution at the DEA
Wed
Leon Rasheed
Centrelink
Centrelink Update – Managing Growth
Mon
Mary Brady, Sandy Kosina, Patti Neuman - CNYRIC
CNYRIC Student Information System
Wed

6. Presenting Partners - Thank You!
Jim Damon
CCA
Model 204 V6R1 – Coming Attractions
Mon
Pete Burlow
Software Europe
Sirius Wishlist Discussion
Wed
Robert Waggoner
Nodus, Inc.
Get Out the Gold Watch and the 30-year Service Pin – Retiring the KEY Attribute
Wed
Steve Nelson
CCA
Java and Model 204: Web Serving or Application Development – It's Your Choice
Tue
Tony Pickering
Yoda Software
Power Editing With Xtend
Mon

7. User Language training with a Janus flair
Robert Wagonner - Nodus, Inc.
User Language training with a Janus flair
Packaged, on-site courses on User Language, HTML, XML and Janus Web Server
Robert Waggoner
Nodus, inc.P.O. Box 426
Decatur, Tx 76234

8. Xtend — PC-based Editor for UL
Tony Pickering - Yoda Software Pty Ltd
Xtend — PC-based Editor for UL
Syntax-aware editor for User Language
integrated help
UL syntax
Model 204 dollar functions
Sirius dollar functions and APIs
Tony Pickering
Yoda Software Pty Ltd
PO Box 496
Leederville, Western Australia 6903
+61 [0]

9. Does Sirius need 3480 cartridge drives?
Question for the System Janitors
Does Sirius need 3480 cartridge drives?
We would like to retire our 3480 (18-track) drives
too costly to maintain
only used to distribute products "on tape"
Most customers prefer download from our web site
save your suggestions (ie better D/R zap UI) for Wishlist
Sirius can receive
3480 or or 36 track, with or without IDRC
3490 "B model", ie 10GB or 20GB before compression
Do you need to receive tapes?
if so, can you accept 3490 (36-track)?

10. What do you think of Sirius' documentation?
Speaking of Feedback
What do you think of Sirius' documentation?
Show of hands, does anyone print the PDF's to read the manuals?
We have been investing heavily in our documentation and want to make sure it is meeting your needs
Jim LaPierre is our tech writer: let him know if you have any comments about
font choices
font size
white space and binding margins
anything else

11. Katie Kodat Awarded Fulbright Fellowship
The Kodats Deploy Overseas
Katie Kodat Awarded Fulbright Fellowship
Will be in the United Kingdom (Oxford) for 4.5 months
neighbors of Matthew Webber!
don't worry, we've tested our IP phone extenders
Then Hungary for 6 months
also has good connectivity
unfortunately the wine is good too, I'm told

12. Enterprise license across all mainframes
CCA and Centrelink Sign Ten-Year Deal
Enterprise license across all mainframes
Reflects ongoing committment of Centrelink management to Model 204
a setback for "alternative technologies"
we hope to make it a defeat of same
Enabled by extraordinary pace of development for Model 204 (and related add-on products)
see Jim Damon's presentation
Creates new challenges and opportunities
"war on MIPs" - see Leon Rasheed's presentation
ultimate scalability

13. Yellow Merges with Roadway
Two largest "Less Than Truckload" (LTL) trucking companies combine
Yellow buys Roadway for $1,100,000,000
Extensive evaluation of all IT to reduce duplication
survival of the fittest
Roadway selected for customer and partner-facing web applications
Go Model 204 and Janus!
primary issues time to deploy and TCO
agility

14. Model 204 Rules the Roost for Massive OLAPI Database
Ultra large-scale repository
continuous real-time data addition
little, if any culling
Complex queries accessing large volumes of data
certified multi-source security filter
Migrating supporting ETL/data cleansing from batch C and PL/I using VSAM staging files to native User Language
takes 25% less CPU
easier to maintain
zero latency
Yet another "modern" replacement sputters
not dead yet, but bleeding profusely

15. Recent (Or Very, Very Close) Releases

16. Fast/Unload 4.1 September, 2003
Multiple output data streams for one pass of file
useful for "culling" data
FUEL structure enhancements
labels
LEAVE IF statement
macro facilities for dealing with field definitions
#IF <field> DEFINED
#ELSE
#END IF
enhanced FUEL program listing
Removed size limit on FUEL programs
was 4MB for compiled program (Centrelink hit limit!)
More #functions

17. Fast/Unload 4.2
March, 2004
Online Fast/Unload ($FUNLOAD) support for multiple output streams
requires Sirius Mods 6.5
FSTATS extended to include procedure dictionary stats
detailed procedure stats only if procedures are unloaded
UAI now unloads UL procedures as well as data
may be suppressed via the "NOPROCS" option on UAI
used with Fast/Reload (in mods 6.5) to reorg procedure files
can provide significant savings in compilation costs
nota bene: may require more buffers for Fast/Reload step

18. Sirius Mods Version 6.5 April 31, 2004 Fast/Reload
LAI support for reloading procedures unloaded by UAI
requires Fast/Unload 4.2
can automatically re-size procedure dictionary (see Tom's talk)
$FUNLOAD support for multiple output streams
even though Fast/Unload 4.1 introduced multiple output streams
Janus Web Server
performance boost when logins required
SETFASTLOGIN parameter
HIGHPRIORITY parameter
better interfacing to RACF for authentication

19. Sirius Mods Version 6.5 April, 2004 Janus SOAP APIs
OO-style interfaces
relieves argument limits on $-functions
simplifies programming, improving programmer productivity
Janus SOAP XPath enhancements
more axes supported
following-sibling, preceding-sibling, descendant-or-self, descendant
ancestor-or-self, ancestor, following
namespace support
significant performance enhancements
Janus SOAP XML conformance
more syntax rules enforced for serialized XML
some compatibility issues

20. Sirius Mods Version 6.5 April, 2004 Janus Sockets SirMon SirFact
support for VSE
http helper wrapper
dramatically reduces coding to consume Web Service - see Daniel Yee's presentation
ftp support for procedure files
SirMon
UTI monitoring - see Leon Rasheed's presentation
SirFact
supports dump of $-lists associated with system objects
supports display of XmlDoc, etc. contents

21. Model 204 and Janus - We Got Game
Two major developments in system architecture are playing to the strengths of Model 204
the emergence of Web Services and Service Oriented Architectures
Web Services & SOA are here to stay, full stop
they will become ubiquitous
a renewed focus on programmer productivity, especially as it relates to application architecture
epic battle is raging between IBM (with Sun on the sidelines) and Microsoft

22. Web Services
Application components that can be called from anywhere across a Intra/Extra/InterNet
Web Services communicate with each other via SOAP
synchronous typically over HTTP
asynchronous via messaging (MQ)
Clients communicate to web services via XML (over HTTP)
Web Services paradigm significantly better than SQL-based middleware:
efficient Stored Procedure/RPC Model
arguments and results not restricted to simple tables
This is a standard Microsoft .NET picture and definition of Web Services. Whenever I find myself agreeing with Microsoft about something, I start to worry. That said, I believe that Web Services provide a significant advance in programming technology, finally enabling efficient distributed applications.
The most important thing about Web Services is that they embrace the Stored Procedure/Remote Procedure Call model for distributed programming. The second most important thing is that the input arguments and output results from Web Services RPCs are not just simple tables, they are tree structured XML documents.
Finally, because Web Services are built on XML and usually transported over HTTP, they are router friendly. Thus, it is simple for partners cooperate via Web Services.

23. Janus Web Server + Janus Sockets + Janus SOAP = Web Services
Janus APIs
User Language
Model 204
Janus Web Server for inbound Web Service requests
HTTP(s)
Janus Sockets for outbound Web Services from UL programs
HTTP(S)
Janus SOAP for parsing/serializing XML
Websphere APIs
Java or COBOL
DB2
Equivalent to Websphere + DB2 + Java/COBOL (and probably CICS)
but simpler
This slide has a base part and then an additional build that appears on the second click. The base part shows that the combination of three Janus products: Janus Web Server, Janus Sockets and Janus SOAP allows Model 204 to participate in a Web Services architecture. Of course this requires Janus TCP/IP Base and Janus Network Security may be involved, but they are left out for simplicity.
The second build makes the point that the combination of Model 204, the various Janus product APIs and User Language programs is essentially equivalent to DB2, Websphere and COBOL or Java. Of course, as anyone who remembers migrating from CICS/COBOL to Model 204 can attest, the integrated application environment provided by Model 204 and User Language is vastly more productive than a non-integrated environment like DB2 and CICS or Websphere.
The simplicity of the integrated environment provided by Janus and Model 204, coupled with the high degree of automation in the Janus APIs allows Model 204 customers to rapidly embrace Web Services.

24. Web Services are Ideal for Model 204
Web Services provides excellent encapsulation
internal architecture of providing server not exposed
SOAP wrappers bring legacy systems into Web Services framework
Number of tiers not dictated by programming paradigm
strictly a function of the application
Large units of work emphasize strengths of User Language
Web Services allow Model 204 to participate in a level playing field with other application platforms. As was pointed out in the previous slide, Model 204 plus Janus and a User Language program is equivalent to DB2 plus Websphere and a COBOL or Java program. All that matters is that once the Web Service request is delivered, it gets processed quickly and the proper result returned. All of the details inside of the Web Service are hidden – thus it is impossible to discern a Web Service implemented in Model 204 with Janus from a Web Service implemented in another system.
This architecture neutrality causes the solutions to compete on the basis of performance and time/cost to implement – both strengths of Model 204.
The use of Stored Procedure/RPC lets Model 204 shine, as opposed to processing individual SQL commands transported across ODBC.
As a final question, how many tiers are shown in this picture? The answer is two – the Web Service and its invoker. Although a particular Web Service might be implemented as a multi-tier solution, that decision is hidden from its caller.

25. Service-Oriented Architecture (SOA)
A way of designing applications using distributed components
usually thought of as using Web Services as the components
all about how to put them together
see Daniel Yee's presentation
For an analogy, think of the difference between designing integrated circuits and designing a PC
the IC's were needed, but reusable
and already existed

26. It's the Scalability, Stupid
IBM's Path to J2EE
It's the Scalability, Stupid
IBM's experiences with 4GL were bad
Cross System Product (CSP)
think IEW gone worse
IBM's experiences with languages worse
think PL/I and PL/S
believed the problem was proprietary nature
seized on Java instead (not Microsoft)
IBM's path was 3GL and multi-tier
CICS + COBOL + DL/1 => VSAM => DB2
always featured strong separation of logical and physical layers
J2EE (n-tier) is a natural progression for IBM

27. Presentation Services
N-Tier Client/Server for Scalability
Network
Application Server 1
Application
Load Balancing Router
Application A
Application B
Data Server 1
Presentation Logic
Presentation Services
Fast
Network
Data Server n
Router balances load between multiple application servers
Backend DBMS used to hold transaction state data
Addresses application server as bottleneck
Even more complexity!
Application Server n
Application A
Application B
App State Data

28. Been There, Done That! 1970 - 1980 Mainframe
Data Server 1
Data Server 2
VSAM datasets
DL/1
Inter-process Communications
Application Server
CICS
Application A
Application B
Application A
Application B
Network
SNA Network
Thin Client
3270
Three-Tier, One Box Web architecture
Browser
&
Java Apps
Green on

29. Overwelmed CICS Programmer
CICS & 3GL (COBOL or Java) Not RAD
Corporate Databases
CICS App 1
3270
map
sup-
port
DL/1
IMS
VSAM
DB2
Overwelmed CICS Programmer
Frustrated End User
CICS App 2
CICS Layers
Remember this picture?
end user needs application
programmer can't keep up
Caused by inefficiency of programming environment
3GL and tedious APIs
too many moving parts and layers
Complex, but Highly Evolved
required for performance
low level API's
Many Moving Parts
difficult to manage
not responsive to change
in spite of great tools

30. J2EE Complexity Versus Scalability
J2EE adds the standardized APIs for scalability
load balancing
state management
etc.
J2EE features formalized physical layers
web server
app server
database
J2EE makes this complexity visible to programmer
just like CICSPLEX
But it does provide ultimate scalability

31. Model Driven Architecture (MDA)
The IBM Solution
Model Driven Architecture (MDA)
Letting a programmer think at a higher level
needed to address inherent complexity of CICS/J2EE
don't eliminate complexity, manage it
The core business of Rational Software
purchased by IBM
Getting a boost from open source tools
May have legs
increases role of "architects"
not focussed at low-level details
probably costs more
still need programmers

32. Microsoft View of the Problem
The Microsoft view according to Bill Gates:
"There is no way to make a million lines of code pretty. We need higher level approaches"
Microsoft is funding an effort to merge native XML and database support into a high-level language
"Programming with Circles, Triangles and Rectangles"
Note the focus is on XML as having "caused" the problem
Prior to Web Services, DBMS APIs were tolerated, but they were still a problem
Microsoft is hedging with MDA

33. Microsoft Productivity Solution
The Microsoft view:
High-level language with integrated DML facilities for DBMS and XML now, concurrency and security to follow.
Sound familiar?
Think Model 204 plus Janus!
Are we on the right track?
Microsoft far ahead of Java/J2EE for Web Services
Microsoft programmer tools (VB.NET) easier to use
I like our position at this point in the race

34. The Model 204 Solution The Best of Both Worlds
The productivity of a 4GL with integrated database and XML processing
high-level APIs handle complexity for you
Complexity of achieving scalability handled by system
programmer only deals with the complexity inherent in the problem at hand
High-level tools for yet more programmer productivity
MDA if it pans out
Avoid's Microsoft's scalability problems and IBM's complexity

35. Life is a race - our customers will be first!
Sirius Product Directions
Life is a race - our customers will be first!
Enhanced support for SOA
SOAP/Web Services
XML Schema support for Janus SOAP
Janus Web Server rules for SOAP envelope processing
tighter integration with MQ
auto-generation of UML & WSDL from Janus SOAP UL code
Single signon (Kerberos)
Programmer productivity
more Object-Oriented Programming features in Sirius APIs
Eclipse plugins for UL generation from UML & WSDL
Web services are an extremely important development that is having an instant effect upon programming architectures. As we shall see in the next slide, Web services solves the middleware problems that have stymied distributed programming efforts. The combination of Janus SOAP and Janus Web Server plus Janus Sockets gives Model 204 a strong presence in the Web Services arena. We will continue to enhance these products to make them easier to use.
Programmer productivity is a very important theme for Sirius. There is widespread agreement that application platforms like J2EE (Java 2, Enterprise Edition) are just too complicated for the average programmer. With Janus and User Language we are creating a platform that is a credible and powerful, yet within the grasp of average programmers.

36. Questions?