Tag Archive: janos

When an operating system like JANOS is created it first reaches out to the world through the simplest communications channel, a serial port. When the developer then wants to interact with the new OS, commands are entered through that Command Line Interface. Soon a reasonable vocabulary of commands are made available for use and this becomes the developer’s Console.

As the operating system finds new ways to communicate with its surroundings it discovers the network and begins to support useful protocols. Logically the first would be some serial channel simulation (Telnet) over which it can offer access to its Command Line Interface for use by others. Eventually, graphical user interfaces emerge and a more modern and user-friendly environment comes into existence.

While the Command Line may seem Old School and it may generate some apprehension on the part of a new user, it is the Go-To utility for the developer. It is here that the system’s vitals can be monitored and the OS can be encouraged to perform for us. It is no surprise that the Command Line has been a key element of the JNIOR from the beginning. We will cover aspects of this user interface that have been enhanced with JANOS v2.0.

Persistent Command History

Every JNIOR, even back to the Series 3, memorized a few commands as you entered them during the Console session. It has always been possible to scroll back to a prior command using the cursor UPARROW and DNARROW keys. This allowed you to scroll to a command and re-execute it by hitting ENTER. You could even edit the command to create a new similar command and execute that. The Series 4 more than doubled the number of individual commands that it would remember during the session.

With JANOS v2.0 this command line history is now persistent. Meaning that you can exit the Console session, return at a later time and scroll back to commands that were entered in prior sessions. This persistent history is saved by User and so each user has his/her own. The same user can even access the Console simultaneously through different channels and retrieve past command history, not have confusion over commands entered in the other session, and see the logical combination of activities later. The number of commands remembered has been expanded to 99. This history, however, remains available ONLY as long as the JNIOR stays powered.


The HISTORY command has always been available and it displays those memorized commands. With Series 3 it was just a few and with Series 4 a longer list. But in those instances it otherwise had little utility.

With JANOS v2.0 the HISTORY command has been expanded to provide better access to the (now larger) record of commands. 

bruce_dev /> help history
HISTORY [index|regex]

index Integer selects command for editing
regex Used for case-insensitive search

Accesses the command line history.

bruce_dev />

For example, if you had entered a command earlier to reboot the JNIOR with some options that you now want to repeat, you can locate that command by typing hist boot. The HIST command being just a shortened alias for HISTORY. The “boot” text is used as a Regular Expression to search the history and any line matching the inquiry is listed. If there is only one matching line it will be selected and brought to the command line to be edited or executed. This command is now very useful.

When multiple lines are listed they are enumerated. You can select any command by entering its index. For example, hist 5 will retrieve the command line displayed with index 5 for editing and execution.


The <TAB> key has become useful in later versions of JANOS. It provides a means of auto-completion. For example, when entering a parameter to a command you can type the first couple of characters of a file or folder name and use the <TAB> key.  JANOS will finish the entry with matching file of folder names. Repeated use of the <TAB> key scrolls through all possible matches and returns to your original line if none meets your need. If the name you seek is displayed you can merely continue to enter your command having been saved from explicitly typing the entire file or folder specification. Warning: You will become addicted to this aid. As much as you want it to, the Series 3 will not do it.

The <TAB> key in fact is context sensitive. If you are entering a REGISTRY command (REG for short) the auto-completion will use known or existing Registry keys instead of file or folder names. In addition, if you have entered the REG command, a Registry key and then the equals ‘=’ sign, if you immediately hit <TAB> (before any space) the current key’s value will be supplied. This is very useful, first if you cannot precisely remember a Registry key and then if you only want to modify the existing value slightly.

The context for auto-completion may be ambiguous in some places. JANOS may offer Registry keys when you in fact desire a Filename. As an alternative to the <TAB> key in those situations, if you need a file name you may use the Ctrl-F keystroke. Similarly, if you need a Registry key, you can use Ctrl-R.

At the beginning of a line you can enter the first character or two of a command and use <TAB>. This will auto-complete with valid commands and even offer matching commands from your command history.  But, of course, some people do like to type.

Finally, imagine that you have just loaded an unruly named UPD file into the /temp folder and need to execute a manual update using the JRUPDATE command. The following generally builds the command for you without much thought:

jru<TAB> -fup t<TAB>/<TAB>

The above sequence could save you from typing something like this:

jrupdate -fup temp/janos-2.4.2.upd

This is best experienced through experimentation. Give it a try.

That command, by the way, would update the operating system and only the operating system on the JNIOR.  The -U option schedules the update provided by the UPD file; The -F option (which can be specified as show or as a separate option and anywhere in the command) answers Yes to the confirmation prompt; And, the -P option Proceeds after ingesting the UPD file to perform the reboot and associated update.

More thorough updates are completed using the Support Tool and the appropriate Update Projects.


Ten years ago the challenge facing INTEG was to insure the future of JNIOR automation and to continue our commitment to our customers and the industries that they serve. We had been successfully supplying JNIOR Series 3 into growing markets when we received word from suppliers that the heart of the product, its processor and operating system, were approaching End of Life. Moving to a new processor would introduce third-party software potentially completely changing the product as we had built it. That would not be acceptable. Our solution was to insure that new software developed completely in-house built upon, and not altered, the product and its design. It was at that point that the JANOS operating system was born.

As our ability to produce Series 3 JNIOR drew to a close we prepared the release of JNIOR Series 4 running JANOS v1.0. It was a new, faster and more reliable automation controller meeting our demand that it serve as a drop-in replacement for Series 3 and continue seamless and uninterrupted support for all those who had selected JNIOR. It has been a great product and JNIOR Series 4 is current and successful today.  It remains the choice if flexibility, reliability, long-term availability, and unprecedented personalized customer support are of concern to you.

With a decade of JANOS v1 behind us the time has come to introduce JANOS v2 as the most reliable and most capable release to date. Unlike other version 2.0 products, JANOS v2 is not a complete rewrite, it does not change the way you see or do anything, and does not introduce risk or a new learning curve. It continues in our tradition of maintaining backwards compatibility while expanding the value the operating system offers developers. The JNIOR will remain solid and reliable for years to come. We look forward to a Series 5.

In addition to normal corrections and performance improvements here is some of what is new in v2.0:

  • Improved diagnostics and logging
  • Experimental access via File Sharing
  • Expanded TLS Security
  • Built-in JSON support
  • Enhanced Batch and Scripting capabilities
  • much more…

Look for JANOS v2 Tips & Tricks here on jnior.com and feel free to contact INTEG Support through our website at www.integpg.com . And by all means you can apply the v2 update to all of your JNIOR Series 4 with confidence. We highly recommend it.

JANOS has implemented a set of time zones that are available but in no means is this a complete list.  There are many territories in the world that either do not observe the time zone that they geographically belong to or they have different rules.  Some locations differ the time zone rules by 30 or even just 15 minutes.  Sometimes governments alter their policies and change the rules that have been in place for years or decades.

This article will describe how to create a new time zone with a DST rule as described in the JANOS Registry Documentation under section 9.2.

The clock subsystem is generally configured using the DATE command. JANOS defines a set of time zones for use in displaying local time. These time zones may or may not utilize Daylight Savings Time (DST).

As there are 24 hours on our clock one might expect that there needs to be only 24 time zones. This however is not the case as some areas offset their clocks by just 30 minutes. In addition, some areas utilize DST while others do not. The following is the default set of time zones. This can be displayed at any time using the DATE -T command.

date command for JNIOR command line

This default list of time zones is likely incorrect for some areas across the globe. INTEG encourages users to let us know when a correction to the timezone tables might be appropriate. JANOS does provide a means by which you may define new time zones with or without DST rules. You may even correct an existing timezone. This is accomplished using one or more Time zones/<name> Registry entries.

Use of a website like timeanddate.com is very helpful for the validation and creation of time zones.

Here I will show you how to create a new Time Zone for Aukland New Zealand.  Timeanddate.com gives us all the information we need in this screenshot.

Information for timezone creation

We see that they are currently observing Daylight Savings Time and will be throughout the beginning of next year since New Zealand is in the Southern Hemisphere.  So now we can follow the following format to build a registry key for the new time zone we will create.

reg Timezones/<name> = <offset>, <desc>, <AbbStd> [, <AbbDst>,
       <stMon>, <stDay>, <stDoW>, <stTime>,
       <endMon>, <endDay>, <endDoW>, <endTime>, <dstOfs>]

We will need to use the full format in order to get the daylight savings time rules implemented. To do this we can enter the following at the command line.

reg timezones/NewZealand = "+1200, New Zealand/Aukland, NZST, NZDT, 
       SEP, 27, SUN, 200, 
       APR, 5, SUN, 200, 60"

The registry tab could also have been used to create the key. That would look like this…

In either case we get the same result. We can now issue the date -t command to see our newly created time zone.

date -t command for JNIOR command line

A reboot is needed to complete the registration of our newly created time zone.  After the reboot there is only one more thing to do.  Tell the JNIOR to use it.  For example, date NZST.

There you go!  The new time zone has been created and the JNIOR is now using it.  As mentioned above, it is recommended to tell INTEG of missing or incorrect time zones so that we can put it in the JNIOR but creating a custom time zone will get your JNIOR to start using the new rules immediately. 

As always, thanks for using the JNIOR!