... perhaps because the tmp directory for your user id is full.
You may see this error message at the top of your browser window:
after trying to start the TSO shell:
This may happen when using our sandbox environment.
If you do see this error message, use your sandbox zFS files:
Navigate to the /tmp/rdt_RDT0xx (where RDT0xx is your sandbox id) and delete the contents of that directory. Alternatively you can delete the entire /tmp/rdt_RDT0xx directory.
Modified on by Gary.Mazo
In this post, I will briefly explain how to test for the POODLE vulnerability with a tool called OpenSSL (https://www.openssl.org/about/) (With much thanks to Jeff Rodriguez for the original information on OpenSSL)
You can also read the official advisory regarding the POODLE vulnerability in the IBM support advisory bulletin.
If you have one of the more common Linux distributions OpenSSL may already come with your installation. To find out, type
on your command shell. If the command is successful, and returns with something like this:
you have openssl.
If you don’t have openssl on your system, you can download one from openssl.org.
Once you have openssl, you can test the POODLE vulnerability by issuing this command
openssl s_client -connect ibm.com:443 -ssl3
Note that ibm.com:443 is just an example. You should substitute "ibm.com:443" with the host and port of the server that you are testing.
You server is not vulnerable if the host and port you specify reply with the following headers:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 0 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Protocol : SSLv3
Cipher : 0000
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1414105008
Timeout : 7200 (sec)
Verify return code: 0 (ok)
If the above check returns the actual certificate, your server is vulnerable.
You should verify that both –ssl3 and –ssl2 protocols are not accepted by the connections.
You can also test that the connection does support the TLS protocols:
openssl s_client -connect ibm.com:443 -tls1
which should return the public certificate of the connection:
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
depth=1 C = US, O = "GeoTrust, Inc.", CN = GeoTrust SSL CA
depth=0 serialNumber = …, C = US, ST = North Carolina, L = Research Triangle Park, O = IBM, CN = redirect.www.ibm.com
0 s:/serialNumber=…/C=US/ST=North Carolina/L=Research Triangle Park/O=IBM/CN=redirect.www.ibm.com
i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
subject=/serialNumber=…/C=US/ST=North Carolina/L=Research Triangle Park/O=IBM/CN=redirect.www.ibm.com
issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
No client certificate CA names sent
SSL handshake has read 2418 bytes and written 423 bytes
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Protocol : TLSv1
Cipher : RC4-MD5
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1414105524
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Modified on by Mike_Fulton
One of the cool new features we added in MVP4 is the ability to browse very large files. We heard back from a number of customers that a really common task is to be able to read (but not necessarily change) a very large file. Perhaps a listing file from your COBOL compile? Perhaps a log output file from your application?
This presented a few challenges. We didn't want to provide a bunch of new buttons to browse files instead of edit files. We worked through some scenarios. JES output files were easy to deal with, because they are inherently read-only. So, we just changed our code to switch from an edit session to a browse session. For very large files, we ask you if you want to switch over to browse mode today. This last situation isn't ideal since it isn't automatic. We will work on improving our support to make this more automatic in the future.
We also wanted to provide really fast performance for browsing very large files. We tackled this head on. When the browse session is first launched, we only pull down a few pages of data to display on the screen. We can do this very quickly, and often that can be enough, if you just want to check something at the start of the file. There are a couple other common things people want to do. One is to go to the end of the file (imagine this is a log file and something went wrong at the end). The hot key for end of file (ctrl-l in a Linux web browser) is supported in browse mode. We send a request to the server for the number of lines in the file, then request the last few pages of the file be returned. We do need to scan through the file to get to the end. There is no magic here. But it is as fast as any other file browser. Since the file is being treated as read-only, we cache data in the web browser as you move around the file and data only needs to be pulled down from the server as you need it. Similarly to ctrl-l, we support specific requests to go to a particular line number.
Being able to move to a particular line is kind of nice, but you also want to be able to search for particular strings, forward or backwards from your current location. We support this as follows:
If the string is already in the web-browser buffer, the search just moves to that location and highlights the entry.
If the search moves beyond the web-browser buffer, a request is sent to the server for a search from a particular line and column, either forward or back
The server returns coordinate information for a maximum number of occurrences (to prevent downloading too much data) and for a maximum search distance (to prevent the UI from becoming unresponsive or the server having to do more I/O than necessary). If no results are returned, but the entire file hasn't been searched, the UI will automatically send the next search request. This lets you cancel the search quickly if you made a mistake.
We optimize the operations as best we can. For example, we can scan to a particular offset in a zFS file efficiently, but we have to compute line numbers. In sequential files, partitioned dataset members and JES files, we can count lines easily (as records), but we can't efficiently search to particular offsets. We've written the back end resource server in an object-based way (it's C code, with some assembler thrown in) to provide core services for each of the different types of files we support.
Overall, we have a responsive, browser that is nicely integrated into our general editing framework, enabling you to work with different types of files without hopefully even thinking about what's going on under the covers.
Modified on by RD_Traveler
Rational Developer Traveler MVP4 (1.0.4) is now available, and can be accessed in a hosted environment or installed locally. (If you would like to try RD Traveler in either environment, let us know and we'll help you get started)
Updates for MVP4 include:
zFS File System
- RD Traveler can now be used to explore and edit files on the zFS file system. The file system can be explored using the zFS Navigator, which can be accessed from a new option in the Home view, or from a new option on the "Hamburger" menu (the button with three horizontal lines in the upper left hand corner). The features provided by the zFS Navigator view are similar to the MVS Navigator view, including the ability to create new folders and files, delete folders and files, and open files in an editor.
File Browser - A file browser has been added for viewing large files, or files that are located on the job entry system (JES). When opening a file that is larger than 8 MB, the editor will now display a message indicating that the file needs to be opened in the file browser. Files that are located on the job entry system will automatically open in the file browser as well. When opened in the file browser, a fixed number of lines is loaded from the server at a time (i.e. a page), and more pages are loaded as the content is scrolled in the editor. To quickly navigate to a specific point in the file, the 'go to line' option can be used (ctrl+l on Windows), or the scroll bar can be quickly dragged to a specific point. The pages between the previous location in the file and the new location in the file will not be loaded from the server, which significantly improves runtime performance. To quickly search the file for a specific value, the file search option can be used (ctrl+f on Windows). The search is run remotely, on the host environment, and selecting the option to view the 'next' search result in the file skips over all pages between the current page and the location of the search result.
C/C++ and PLI Support - Experimental support has been added for C/C++ and PLI, which includes an outline view and syntax highlighting for these types of files in the RD Traveler editor.
zOS Support - The WebSphere Liberty Profile instance used by Rational Developer Traveler (i.e. the Application Server tier) can now be installed on zOS. This eliminates the need for an x86 Linux or zLinux environment when installing RD Traveler.
We are excited to hear what everyone thinks of these new features. If you have any questions or comments about MVP4, or RD Traveler, feel free to post them here.
Modified on by bsvihovec
Rational Developer Traveler MVP2 (1.0.2) is now available, and can either be accessed in a hosted environment or installed locally. (If you would like to try RD Traveler in either environment, let us know and we'll help you get started)
Now that MVP2 is available, it is time to share the enhancements that we are considering for MVP3, which include:
Job View - A Job view will be provided so that users can view and manage jobs on the host environment. To find a specific job, or jobs, the following filters will be provided for this view; Name, Owner, Queue, ID, and Class. Once a set of jobs have been located, users will be able to sort the jobs in ascending or descending order by clicking on a column header in the job listing table. Users will also be able to Cancel or Purge one or more jobs by selecting the jobs in the job listing table and choosing the appropriate action.
Job Status View - The Job Status view will provide additional job information that is not found in the Job view, including Completion Status and links to the job output. If the job was submitted with RD Traveler, the Job Status view will also contain a link to the JCL that was used to submit the job. The Job Status view will be accessible from the Job view by clicking on a job ID, or from the JCL Submit progress message that is displayed after pressing the Submit button in the JCL Editor.
TSO Shell - A TSO Shell will be provided for invoking TSO commands on the host environment. A user will be able to create more than one shell instance at a time, and each shell instance will have its own command history that can be accessed by pressing the up arrow in the command line.
We are excited to hear what people think of these new features, and we are even more excited to make them available to everyone in our next release. If you have any questions or comments about what we are planning for our next RD Traveler release, feel free to post them here.
Modified on by Gary.Mazo
In their recent blog posts, Brian and Mike mentioned security features such as password protected accounts and enabling SSL connections to the RD Traveler resource servers.
In this post and in follow up posts I will take this topic further and explain details of what we do in RD Traveler to enable security end-to-end.
This first post is an introduction to security aspects of web communications and of the RD Traveler sites in particular. In the next post I will describe details of how you can enable a secure communication between the web browser and your on-premse version of the RD Traveler web server.
If you are not familiar with acronyms like "SSL", "TLS", "SHA", "DES" etc. this series of posts is for you. You will learn about basics of securing a network connection using industry standard technologies. If you are a system administrator in charge of installing the RD Traveler on premise, even if you have experience in working with web applications, you will benefit from learning how to enable your RD Traveler installation for secure communications.
It is typical for all web sites providing a log in capability to any kind of private or sensitive information, to provide a secure connection. A "secure" connection for a web site means that the identity of the site is verified by a known authority and the communication with the site is encrypted using standard encryption protocols. I will explain more about site identity and encryption later.
How do you tell if a particular web site is secure?
If you ever used a web browser, you may have noticed that web sites have an indicator, provided by the web browser, that the connection to this particular web site is "secure". This indicator may take different forms in different browsers. For example, Google Chrome shows a green lock at the beginning of the address bar to indicate that the site is secure:
Firefox browsers may show different color locks for secure sites with color of the lock signifying various levels of site identity validation:
Whatever pictorial indicator there might be in a specific browser, the web address itself for secure sites always starts with "https://" as opposed to insecure "http://". Many sites, even if you explicitly enter "http://" at the beginning of the web address, will switch automatically to "https://" (This is the behavior of the RD Traveler server, but more about this later). The "s" at the end of "https" stands for "secure" and indicates that the communication to this site is using a set of security standards commonly known as SSL and TLS.
The first main goal of the secure communication is to verify site identity. This is necessary for the clients to be sure that they are connecting to the site that they think they are connecting to. It might sound silly but consider for example a simple typo in a web address which leads to a malicious site that exploits common misspellings of popular legitimate sites. Site identity must be verified by an independent organization that maintains and verifies site information and, many times, reputation. These organizations are called Certificate authorities (CAs) and they issue certificates for known web sites. Certificates form a "chain of trust" that is used in Public Key Infrastructure (PKI) to positively establish the identity of the certificate owner.
Once the identity of the site is established, the second major part of the secure communication is establishing a secure connection which encrypts all information exchange between the site and the clients using the security keys. The security key exchange is part of the protocol handshake that takes place after the identity of the site is established.
All popular web browsers and other clients accessing the internet have databases that store signed certificates of registered CAs and sites that are registered by these CAs. The certificates are encrypted with keys issued by CAs and are only available to the registered sites. This is how browsers and clients know that the identity of the site is legitimate.
If anything is suspected to be wrong, or if a browser does not have a certificate key for a particular site, but the site insists on secure communication, the browser will issue a warning similar to the one issued by a Chrome browser shown here:
This does not necessarily mean a bad thing, as in this case when the warning is about the "localhost" server that runs on my laptop and which only has a self-signed certificate. Self-signed certificates are not issued by CAs and are usually temporarily generated for testing or development purpose, as is the case with my laptop. If you run RD Traveler server within your Intranet, it is usually ok to have either a self-signed certificate or a certificate from your company's internal certificate authority. The process for enabling your company's internal certificate is similar to enabling an external one but you will need to manually import the certificate authority information into your browser certificates database so that the browser will know not to issue the warning.
In general however, you and your clients should be very cautious if you get a warning message from a web site. This is why the RD Traveler sandbox site is secured with a proper certificate as indicated by the lock on its address bar:
This is why it is also important that if you get an on-premse version of the RD Traveler and run it for you users, you secure it with a proper certificate. In my next post, I will show how to enable the RD Traveler application server with a certificate. Stay tuned.
Modified on by bsvihovec
As you may have read, version 1.0.1 of Rational Developer Traveler is now available, and can either be accessed in a hosted environment or installed locally. (If you would like to try RD Traveler in either environment, let us know and we'll help you get started.)
While we continue to gather feedback on version 1.0.1, we are also working on the next version of RD Traveler. We are excited about the new features that are being added in the next version, which include:
* Removal of the Rational Developer Traveler ID - Based on our own usage of RD Traveler, and on feedback we received from version 1.0.1, we have decided to remove the Rational Developer Traveler ID and allow users to access RD Traveler with just their TSO Credentials. With this new approach, it is much easier to manage an RD Traveler installation, and a unique RD Traveler ID is no longer required to access a specific host environment. The RD Traveler login now looks like the following screen capture. To login to RD Traveler, a user chooses a host environment from the list and enters their TSO credentials for that environment.
* Support for Sequential Datasets - Sequential Datasets can now be accessed in RD Traveler, including the Navigator, Editor, and Compare views. Also, similar to the Partitioned Dataset (PDS) support provided in version 1.0.1, a Sequential Dataset can be created using the 'allocate like' feature in the Navigator.
* Line Wrapping Support - The RD Traveler Editor has been updated to support smart line wrapping when the end of a record is reached. When the cursor wraps to a new line, it is automatically placed at the same indent as the previous line.
* PDS Member Alias Enhancements - If a PDS member alias is updated, RD Traveler will honor the alias and keep it as a true reference to the underlying PDS member. In version 1.0.1 of RD Traveler, updating a PDS member alias would result in a copy of the original PDS member being created and the alias being removed.
We look forward to getting feedback on these new features when they become available, and to hearing what other features might be necessary to build a web based 'TSO/ISPF Companion' for Enterprise Application development.
Thanks for reading!
Modified on by Mike_Fulton
Many development environments have error message display integrated into your editor. After you have built your code, you can see where the errors are in your application without having to look at the output from a compiler. We provide the same capability in the JCL and COBOL editors in RD Traveler.
In this blog, I will describe how we process error messages.
Submitting a Job
When you first edit a JCL or COBOL PDS member, RD Traveler doesn't know about any errors that might be in the code, so the editor has no special annotations to indicate errors.
When you submit JCL, RD Traveler scans the output, looking at each step. On each step, we look at the program name and see if we have an error parser for that program. If we do, we run the error parser and it examines the output files from the step. Which files the error parser looks at varies from program to program (for example, the C compiler writes errors to SYSPRINT whereas we provide a user exit for the COBOL compiler and errors are written to SYSXMLSD. The errors from each of the steps are aggregated and sent back in a standard format to the web client.
The web client then displays error messages on the associated step. In this example, the program has errors on the CREATE and the CCOB steps
If you hover over the error marker, you can see the specific errors:
The web client also remembers the job that was just submitted and associates that job-id with all the source files that had errors in them. So, if you open a source file that had errors in it, those errors are highlighted in the corresponding editor. This gives you a nice way to be able to see all the errors from your compilation steps. In the following example, I've modified the COBOL source and submitted the JCL. This time, the compilation (and the following LINK step) have failed:
If I hover over the COBOL source dataset name and click on it in the JCL, it will open the COBOL source code in another tab, with the errors highlighted. I can use the error marker gap on the far right to locate the offending error in my code (in this case, a typo of FE instead of FD).
If the error had happened in a COBOL copybook, the same process would work - we track errors down to files referenced from other files (as long as the program gives us the information about what file is referenced from where.
Modified on by bsvihovec
When a resource is opened in the RD Traveler Editor, the Content Type of the resource is determined by looking at the current low level Qualifier to see if it contains the values "COBOL" or "JCL". If one of these values is found, the Editor is configured to display the resource using the corresponding Content Type. If neither of these values are found, the resource is displayed using a basic Text content type. (NOTE: The rules for determining the Content Type of the current resource are currently being reviewed based on user feedback. We will post the updated set of rules when they are available.)
If a resource is not located in a low level Qualifier containing the value "COBOL" or "JCL", yet the resource really does contain COBOL or JCL content, you can easily change the configured Content Type using the options found under the "wrench" icon in the upper right hand corner of the Editor:
(Click on the wrench to configure RD Traveler Editor Settings)
Clicking on this icon displays the following menu:
(RD Traveler Editor Settings menu)
The RD Traveler Editor Settings menu is broken down into two categories, which are separated by a horizontal line; 1) Editor Preferences, which include the options displayed above the line, and 2) Editor Properties, which include the options displayed below the line. The difference between Preferences and Properties is that Preference values are saved for the current browser, and will affect all editor instances opened from within the same browser, while Property values only affect the current editor instance, and will be reset to the default values if the editor is refreshed.
To change the Content Type of the current editor, simply choose a different content type from the options displayed in the list, which currently include; COBOL, JCL, and TEXT. After the selection is made, the editor content, including the outline view and related tool bars, will be re-rendered using the selected content type. It is worth noting that you cannot change the Content Type of the current editor if it contains unsaved changes. If the editor is "dirty", a message will be displayed when a new content type is selected, indicating that the content type can not be changed.
In addition to the Content Type setting, the Editor Settings menu also provides a Read Only setting, which can be used to reduce the risk of modifying a file that is not marked as read only by default. If the file cannot be modified by the current user, the Read Only flag will appear as checked and disabled in the Editor Settings menu when the menu is displayed.
In the future, Editor Properties should be managed by RD Traveler, so that the configured values are available on any device. For now, the ability to change the Content Type as necessary should make it possible to work on a resource without having to modify the low level qualifier or copy the resource into a different low level qualifier.
Modified on by W4V9_Mike_Kucera
RD Traveler has a nice feature that lets you run a job by submiting a Job Control Language (JCL) file from the editor. Progress reporting on the status of the job is shown while it is running. When the job completes any error or info messages that were generated are shown directly in the editor. (Watch a video of this in action.)
A job run may result in the generation of output datasets. We want to make it easy to find and view those datasets after the job completes. Since the job is submitted directly from the JCL editor we think it makes sense to annotate the JCL code with links to the output datasets.
To see the links in the JCL code simply hold down the Ctrl key (command on a mac). Any references to data sets in the source will be highlighted as HTML links. Click on a link to open a new tab with the contents of the dataset.
Users are not clairvoyant
Holding the Ctrl key to see the links is a nice feature, but I worry that it will have usability issues. The biggest problem is discoverability. How does the user know that Ctrl is used to show/hide the links? We can't expect a new user to just know that somehow. So its up to us to teach the user that this feature exists. How do we do that? Documentation?... ha ha that's funny.
The Ctrl-click feature is not new to Orion, it has a lineage coming from Eclipse. In the Eclipse Java editor you can hold Ctrl and every identifier in the source turns into a link. Clicking one causes the editor to jump to the declaration of that identifier. This is nice, but its actually only one of at lest three options to access the “Open Declaration” feature. You can also hit F3 or select “Open Declaration” from the context menu.
My experience watching students use eclipse is that initially they always use the context menu option. When I tell them they can just use F3 or hold Ctrl I get a reaction like “Oh, that's cool”. But if I wasn't there to tell them how would they know?
The Link Dialog
Our solution to this problem is to provide another way to get at the links, one that is much more obvious.
We added a highly visible button to the top of the JCL editor that says “Referenced Datasets...”. Clicking the button opens a pop-up dialog that lists all the links that are available in the file. All the information about the data sets is available, including the full names. The table is also sortable.
There is a subtle but very important element to the dialog. At the bottom it says “Hold Ctrl to see links in source”. This is our attempt to teach the user about the Ctrl-click feature. The theory is the user will have no trouble finding the dialog, and if they notice the message at the bottom then they will have also learned about the Ctrl-click option.
So now we support two workflows that we believe are complimentary. If the user wants to focus on the datasets they can open the dialog and see them all in one place. If the user is focusing on the JCL source and they want to quickly jump to a dataset they can Ctrl-click. The first workflow is easy to find and teaches the user about the existence of the second workflow.
Its all good, in theory...
Of course everything I have said to this point is basically just a hypothesis. We believe that the dialog will be discoverable and easy to use. But how do we know that for sure? The only way is through real usability testing, which we plan on doing soon. We will see if our hypothesis holds up or not, but I am optimistic.
Modified on by W4V9_Mike_Kucera
Themes and Colors
The RD Traveler user interface is based on the Eclipse Orion project, which gives us a nice framework for building a browser-based cloud editor. We reuse and extend their editor, settings pages and various other widgets.
One of the nice features that Orion provides is the ability to customize the color theme of the editor and the overall UI.
We are hoping to impress ISPF users, and ISPF is a typical green-screen mainframe application. This leads directly to the logical conclusion that we need a dark mainframe theme. This turned out to be more challenging than expected.
You can customize the editor using several of Orion's pre-defined color themes. Its even possible to create your own themes.
The Mainframe Classic Theme
Providing a dark mainframe theme turned out to be more challenging than I initially expected. The Orion UI is designed in a way that assumes the color theme has a light background. As soon as I set the background to black all of the text became unreadable because it was black text on a black background. I had to and add new color settings for several areas of the UI that previously were hard-coded and assumed a light colored background.
Furthermore our Navigation page is not taken from Orion. My team built it from scratch using the Dojo toolkit, which has its own approach to themes that is completely separate from Orion. It took some work to get the Dojo widgets to respect the Orion theme.
Here is the result, the amazing new Mainframe Classic theme, next to the default light theme for comparison.
The Settings Page
The Orion settings pages are used to change the color themes. There are actually two separate pages, one for the editor theme and another for the UI theme. We feel that this is a bit cumbersome and have considered merging them into a single page on the future.
One of the really nice things about Orion themes is that changing the theme immediately effects all open tabs. You don't have to go close and reopen every editor tab, then all pick up the new theme setting instantly.
Orion makes it very easy to customize a theme using their color picker. Simply click on an area of the UI that you wish to change and then pick a new color. The modified theme can then be saved under a new name.
Editing COBOL code in a browser using a dark mainframe style theme? What's not to like!
Modified on by bsvihovec
In this blog entry, I will provide a basic overview of the RD Traveler Web Client, starting from the Home view, which provides easy access to RD Traveler's key features.
The RD Traveler home view can be accessed using the following URL: http://<domain>:<port>/RDT/home/Home.html (where domain and port values are specific to your installation). If this is the first time the application has been loaded, or if an automatic logout has occurred, the RD Traveler login view will be displayed:
(RD Traveler Login View)
After logging in, the browser is automatically re-directed to the RD Traveler Home view:
(RD Traveler Home View)
On the Home view, the following operations are available:
Explore - Selecting this option will open the RD Traveler Navigator view, which can be used to explore the currently configured host file system.
Recent Files - The Recent Files view displays the last 20 files that were opened with RD Traveler, in any browser and on any device, making it easy to access files that were opened with different browsers or devices. Selecting a file from this view will open the editor on that file.
Settings - Selecting this option will open the Settings view, which can be used to configure the settings of RD Traveler
Logout - The Logout option will logout the current user
From the application header, which is displayed on every view in the RD Traveler web client, the following options are available:
RD Traveler Icon - Clicking on the RD Traveler icon will open the Home view
Menu Icon - Selecting the Menu icon will display the following options, which makes it easy to navigate between views without having to access the Home view:
(RD Traveler Main Menu)
User Settings - Clicking on the User Settings icon will display the following options, which also makes it easy to access the settings page or to logout without accessing the Home view:
(RD Traveler User Menu)
It is worth noting that since the RD Traveler application is a three tier system, consisting of the Web Client, WebSphere Liberty Application Server, and Host Server, there are two sets of credentials that are required to access the Navigator view and the Editor view. The first set of credentials, which provides access to the WebSphere Liberty Application Server tier, are also required for all other views within the application. The second set of credentials are used to access the Host Server tier, and are not required to be the same credentials as the Application Server tier. When the Navigator view and the Editor view are first opened, if the Host credentials have not been provided, the Host Login view is automatically displayed:
(RD Traveler Host Login View)
While using RD Traveler, if the user credentials are no longer available (i.e. automatic logout after a specified amount of time, expired credentials, etc), a message that looks like the following will be displayed:
(RD Traveler - Authentication Required)
Clicking on the link provided will open the appropriate login view in another window, and the operation can be re-run once the credentials have been provided.
In addition to the Home view and menu options listed above, which make it easy to access the different views provided by RD Traveler, the power of the modern web browser can also be leveraged to enhance the user experience. For example, direct access to specific views can be bookmarked or shared with others, which is possible because the URL of each view includes a resource name (i.e. localhost:9080/RDT/edit/edit.html#/ZOS/MVSFiles/USER26.ANAGRAM.COBOL/ANAGRAM). Also, multiple instances of the same view, operating on the same resource or different resources, can be opened in separate browser windows or tabs, which means that views can be stacked or spread out across multiple monitors, etc.
This blog entry has provided a brief guide to getting started with RD Traveler. In future blog entries, I will cover some of the additional features that are provided by RD Traveler, but for now, let us know if you have any questions or comments.
Modified on by Mike_Fulton
When we started working on developing a web client for editing, a big concern I had was whether this would even work. Would it be fast enough that it could compete with a 'native' editor like vi or emacs on Unix systems or ISPF on z/OS?
My thoughts were that if it was sluggish, it would never be truly successful. No one wants to wait around to do basic things like editing a file.
I became hopeful when I saw Orion - an open source editor that can load very large files in a couple seconds (probably faster now), and provides a good edit experience.
So, we built our own editor framework on top of Orion and created a separate navigation framework for looking at datasets on z/OS, which is our first file system we are playing with. We now have a 'resource explorer'.
Our 'resource explorer' consists of 3 major components:
Web Client: This is the interface to the user, and is built on dojo and Orion.
App Server: All requests for resources go to the app server, which we run on WebSphere Application Server Liberty 8.5. The App Server also manages information about the current logged-in user, such as credentials and settings.
Resource Server: The app server sends all requests for resources to the resource server. Our intent is that there could be many resource servers on a variety of platforms in the future, but for right now, we've got a z/OS Resource Server, which manages datasets (directories) and members (files), submitting jobs (processes), and managing results from submitted jobs.
To navigate through thousands of datasets (think of them as simple directories) on a z/OS server, and then to navigate through possibly tens of thousands of dataset members (think of them as flat files) isn't going to be super fast if you take a simplistic approach to the problem of just downloading lists of datasets or members. And uploading large files every time a change is made is going to be sluggish too. Especially for traditional COBOL programmers that like to put entire programs in one big file.
So we organized the datasets into a 'hierarchy' - which is fairly obvious, but hasn't been done with many of the current remote z/OS development environments out there. It looks something like this:
Next, we stream-lined dataset requests, so that only the datasets initially being displayed were requested, with the other datasets asynchronously being downloaded. The image that follows shows the network request for the first page of entries (0 to 19). Subsequent requests for more items are farther down:
We will do the same thing for dataset members - grabbing just the first 20 or so entries to populate the display, then getting the rest in the background. Again - for people that do web-applications, this is fairly obvious, but many of the current remote z/OS development environments aren't optimized to break work into chunks, doing things asynchronously to provide a nimble client..
Now - what about actually editing the file? It turns out that Orion can pull down big files fast enough that we haven't found the 'read' of the file to be too onerous. But... When someone updates the file, we don't want to send the entire file back up-stream every time. We've gone to quite a bit of trouble to make reading and writing files not only fast, but also reliable (hey - if you can't trust the basic read/write of a tool, you just won't use it).
Making Reading And Writing Reliable
We use the ETag technology built into web browsing so that we can ensure that the files we are reading (and more importantly, updating) are what we expect. When we read a dataset member, we get the timestamp for the file and send it along with the contents. Later, when an update occurs, we flow the timestamp back to the server and, before the update, we can check that the file we are updating really is what we think it is (so if someone changes it from another client, we can detect it, because the time stamp will have been updated). This makes editing the files safe, even in a multi-user environment. We flow timestamps for a bunch of other operations too - like touching files.
Making Update Fast
One thing that drives me nuts is when you make a one line (or maybe even a one character) change, and it seems to take forever to do the save when the file is remote. That doesn't happen with our technology. When you open the file to edit it, we pull it down and put a copy of the original file in memory. When you hit 'save', we do a diff of the file to be saved with the original file in memory. Then, we send the diff command to the resource server (via the app server), which runs the command. So - if you change one line of text, all you send to the server is a one line 'change' diff command. Super fast. The image that follows shows the network request, sending a one line 'diff' command for the one line of text that was changed in the file being saved:
There's a bunch of other things I think are pretty cool about our 'resource explorer'. I plan to write about some of them soon, so stay tuned.
Modified on by Gary.Mazo
Lately, I have been dealing with HTTP a lot (specifically, with concepts used in the Orion project ). Perhaps given the vast richness of the protocol, it is not surprising, that coming up with good material that explains all the details of the protocol is really hard.
Mind you, there is tons of specification material on W3.org and it's all good as the specifications go but if you ever tried to read (and more importantly understand the intricacies of) some of HTTP specs, you'd know it's not a walk in the park, especially for a seasoned programmer that is trained on Intel assembler or even Java. I mean it's all well and dandy and you can spend an hour or two reading through the dry prose and even get all the concepts.
But the real examples are sorely needed for complete grokking of the beauty of HTTP.
So every time I run across a gem of a sample or a clear and concise interpretation of some very useful HTTP concept I grab it and stuff it in my bookmarks. Here is a sample of an HTTP concept of conditional headers made easy. Enjoy.