TSI Y2K Related Tools, Especially the New
N2OSCAN Utility in N₂O

We're seeing a lot of requests on the SAG-L for Y2K tools for NATURAL. A variety of companies are responding with tools and services for the conversion effort. TSI is unique in that we know the worldwide ADABAS/NATURAL market, we have talked to hundreds of sites about their Y2K needs, and we listened.

This background and marketing research has led to the development of our new N2O N2OSCAN feature. We believe this is the missing piece in the Y2K "puzzle" for many customers.

We decided to put an immediate and extensive effort into this N2O feature, and the result is an incredibly robust tool. Within N2O, it is named "N2OSCAN".

I challenged our technical development staff to provide the capability within N2O to "attempt to find all the date variables and logic in NATURAL applications by looking for user-defined strings, recording the matches, and reporting them." From this, we have a basic design to allow the user to state parameters which in English would mean:

N2OSCAN does this. It processes the source of all NATURAL objects (programs, maps, etc.) which make up the selected application and reports on (or records for future lookup) all matches.

You might typically scan an FUSER for one library (application) at a time. But, you can scan over a library range. Then, the reports can answer questions like:

• What libraries have been scanned? By whom? When?
  
• How many source objects (programs, etc.) are in the library or libraries I scanned? (Again, not limited to a library. You can scan an object (program, etc.), range of objects, library, range of libraries, or all code on the FUSER)
  
• How many total lines are in what I scanned? Comment lines? Non- comment lines?
  
• How many objects have date strings (or whatever character strings I scanned for, like telephone, zip, ssno, etc.)?
  
• How many lines in what I scanned have date strings?
  
• How many lines in each object have date strings? In comment and non- comment lines?
  
• How many times was each actual string found?
  
  

You would presumably like to list the program on-line and see the matches highlighted. You might want to run the entire process in batch so that you can have nice printouts from which to work to make date-related code changes.

Don't worry, the N2OSCAN feature is properly controlled within N2O so that only authorized personnel may use it. And, we have the proper controls to prevent old/new scan confusion. That is, if you attempt to look at some recently changed source code combined with older scan matches, you will receive a warning that you should re-scan. Also, old scan data can be deleted by the user for user-owned scans or by the the N2O administrator for any and all scan data.

The combination of TSI products is the best possible "solution" for the "average" site's Y2K needs. Sure, there are the huge sites that simply want to throw $20M at the problem and make it go away with fancy products and/or consultants. And, there are sites at the other extreme that say they are all set for year 2000, or they only need to convert a few things, or they don't need to convert for one reason or another anytime soon. For the hundreds of sites we've talked to, the majority fall somewhere in between, with a bunch of NATURAL code that needs to be looked at, date logic to be found, and maybe code and data to be fixed, soon.

We agree with what Steve Robinson said recently in his Inside NATURAL publication, basically, "What's the big deal? You've got some work to do. Do it."

I bet every TREETIPS reader has been asked by non-DP-types, "What's this year 2000 problem I have been hearing so much about?" Were you able to explain it? Surely, you could give them some meaningful examples. Did they understand? I'll bet, yes. If non-DP people can understand the problem, it can't be too complex. It is not complex. It is quite simple. I'll be kind and say the problem is one of "oversight". Even little children would be amazed that grown up DP people didn't take the next century into consideration, asking their parents, "Did you think the next century wouldn't come, or what?"

Even though the problem is simple, one can make the solution simple, or complex. The solution may take time, may cost money, and may be a major annoyance, but it does not need to be complex. And, we don't think the data processing world needs any more conferences that go on for a full week dedicated to Y2K issues. Just "do it" - assuming you have the tools.

We believe that many other products on the market fall short (or are too far out) for the typical NATURAL site. For example, some of these products are COBOL oriented, and are (or are going to attempt to be) handling NATURAL simply as just another language with new syntax rules. This won't be successful. NATURAL programs are not invoked via JCL, so you can't see the "trail of execution" like you can in a 3GL COBOL shop. NATURAL programs are restricted in size, and a simple change which makes the program larger may make it fail when compiled. NATURAL is a different environment, not just a different language. How will these products deal with 49 different NATURAL startup scenarios, with different startup parms, FUSERs and FDICs, etc.? A COBOLish solution won't work too well for a 99% NATURAL site. And, if only 10% is done in NATURAL, why get an expensive, overblown tool for NATURAL?

Some of the companies marketing these products know little or nothing about NATURAL. How will they support their products, which suddenly have this new "language" to deal with? Will they support the old REPORT mode, or only the new STRUCTURED mode? Will they be able to change quickly to adjust to NATURAL 2.3? 2.4? 3.1? They don't know that in the next version of NATURAL SAG may change the syntax of the language quite a bit, and that UNIX, VAX, and other versions may have different syntax. (COBOL hasn't changed since 1840.) They don't know the impact of compiling the program against Predict data which might point them at a test database's set of files/fields, which might be different when compiling the program with a production Predict orientation. So, if one were to scan and remediate the source program, which Predict would one use? And, in its next version, the Predict dictionary data layout may be different.

They can't logically or easily convert all NATURAL (or COBOL for that matter) programs without having a view of the database files' field sizes, descriptions, data values. How will they get this? "Send us all your programs, all your PREDICT data, AND all your data files." ???

Do they know that they will have to deal with PAC and its storage of the source code, i.e., it won't be on any FUSER? What about CONSTRUCT, NATURAL SECURITY SYSTEM, NATURAL for DB2, Predict, etc.?

Some of these other products, having a COBOL or 3GL orientation, only work for one operating system such as MVS. (COBOL may look quite similar across operating systems, but the JCL is radically different.) So, what are the VSE, VM, and Siemens folks to do, clearly about 50% of the NATURAL world?

Some of these products go extremely far to recognize and remediate any and all date-related scenarios in the code. What if they only remediate one way or the other, i.e., the expansion method, or the windowing method. (I say there are many other methods. They just don't have fancy names yet.) Let's say they only do it on a data expansion basis (change from 2-digit dates to 4-digit dates, in the program - which would require changes in the related data files). What if that is not what the user wants? Maybe the user wants the windowing technique to be used in one or more particular cases. Maybe there is one application where the credit card expiration date can be easily recognized and handled via the windowing method (if the 2-digit date looks big, it must be in the 1900s, and if it is small, it must be in the 2000s). If the user wants to do this kind of change, which is technically abhorrent but sometimes necessary, like coming to work on Saturday, then let the user do so, in my opinion.

And, if you use the expansion method to remediate the programs, then what about the data? It must be expanded. So, you need to run something to put 19 in front of every year, right? If it is a birth date, 19 would be good, unless you want to be considerate of the elderly and deal with the people born in the 1800s. This works for "present and past" date-related data. If it is a driver's license renewal date, it has to have a 19 put in front, or maybe a 20. So, to repair this kind of "present and future" date-related data, you've got to use that ugly logic one time: if the year looks small, put a 20 in front, and if large, put a 19. Now you've properly expanded the 10 million record file so that you can use your expanded programs on it. Are sites going to send away their huge production files to get expanded?

Some of these products require downloading the application to a PC (a very healthy PC). How? When? What if somebody changes the mainframe programs meanwhile? Are sites going to reload new, hopefully properly remediated, versions? Were they remediated on a PC without testing? Are sites going to wipe out what is there now in that library on the mainframe? Good luck.

Some of these products are more services than software tools, requiring the applications to be sent away for fix-up to another company, sometimes in another country half way around the world. What happens in the months this conversion is taking place? No changes to any production programs until the new modified ones arrive all working perfectly? How did they get the programs to work? With the customer's test data? Real data? Confidential data? Even if they got the programs to compile and execute, this does not mean that the programs will compile, let alone execute, at your home site.

If the customer is being charged on a per-line basis, wouldn't it be best (cheaper) to not involve the non-date-related objects? But, these objects (programs, subprograms, etc.) have to be included if the application is to be understood, and certainly if proper testing is to be performed. Therefore, the charges may be higher than really necessary.

What do these other solutions cost? Probably $100,000 and up, maybe exceeding $1M when per line charges are included. That's just for the tool(s), and doesn't include the consulting costs, either for contract programmer help or for the customers' own people to switch tracks and do conversion for a couple years.

What about liability? What if your code is remediated incorrectly, and causes your organization loss of time, code, or data? Can you ensure that the conversion company or consultants are held accountable? Will they be accountable in year 2000 and beyond? Will they be around then?

We believe the best approach is to keep the NATURAL programs right where the user created them, has them, and wants them - on an ADABAS file (FUSER). The tools should be mainframe-based, preferably written in NATURAL, and therefore working in MVS, VM, VSE, and Siemens.

The tools should be able to obtain a list of libraries and their programs, find date logic (or date-related character strings, with absolute and non-absolute matching capability), record the matches, view the matches in programs, peruse the related ADABAS data fields, and once the user has made all necessary changes, our tools should allow for ease of testing, documentation, seeing the changes to programs and data, etc.

We are perfectly positioned with our N2O N2OSCAN at the heart of this "solution". It costs very little and is easy to use by the customer, whether they use in-house technicians or outside contractors to do the conversion work. Customers will find there is no special training necessary to use this tool, and therefore high-priced consultants are not always necessary to do the conversion work. The tool may have different uses for various departments, more than just for date-related conversion, and it certainly has use well beyond year 2000.

N2O is already the product that identifies libraries and the programs and other objects making up an application, and recording these discoveries in its control file. The user can go through the list of objects, exclude some, use XREF to include/exclude others, and end up with a nice list of what should be N2OSCANned. N2O can be used to migrate all these modules to a Y2K-TEST environment. TRIM statistics can help determine over time which programs are probably the candidates for the scan. Often, programmers have some "junk" modules floating around, and these may or may not be candidates for scanning. Who are we to think we know? The user will have to guide us.

Once you have converted an application, we have PROFILER for NATURAL to help with user testing, whether or not it is date-related testing. I don't see us changing our various products to put any specific date-related orientation into them, i.e., I don't want to change AUDITRE to say, "Show me all the changes to date-related fields, and show me the month 01 as January, etc." I think this would be overkill.

We have PEEK to look into ADABAS files. We have tRelational to look at FDTs, Predict structures, and to view related ADABAS data in various ways. We have CHART for the users to chart their way through the applications. We have ADAREORG to help repair the data, an important part of the puzzle. And, we have the N2O Project Tracking feature to track progress through the entire conversion process.

What we don't and won't have is 3GL support in the N2OSCAN. If you need to do COBOL, FORTRAN, Assembler, JCL, etc., you may want one or more of these other products. If you are 90% 3GL, you probably should get them. If a good percentage of your applications are written in NATURAL, you need our "solution".

We don't and won't have remediation of the code. Can you imagine trying to somehow automatically repair the NATURAL code? Does the line of code MOVE A TO B have anything to do with dates? Could be, especially if #DATE was (or is later) moved to A. But, A is conditionally moved to either B or C. C is put through a calculation resulting in D and E. E is moved to F, and F is redefined to be F1, F2, and F3. F3 is sometimes moved to B. The literal "01" is sometimes moved to B, and the literal "199" is moved to F3. F3 is sometimes compared to A. There is a comment nearby about zip codes. F2 and F3 are passed to a subprogram which puts them in G and manipulates them in some gross fashion. What would we do in a tool to remediate this? Better question is, "How would we automate the process to recognize this in some code and change it to some other code, hopefully guaranteeing some amount of correctness?"

I submit that we should forget about automated remediation, because one can only go so far without running into trouble, and that isn't very far. In the example above, knowing all the facts, it is still unclear if this involves dates, or involves only dates, and is not some common routine to deal with other things, too. If it does involve dates, does it already have Y2K orientation? Maybe it does. Maybe it is a wild scheme like 00 means 1900, 99 means 1999, A0 means 2000, A1 means 2001, etc. We don't know, and an analyzer may or may not be able to figure it out, and who knows if the user wants to change it? I say, "Tell the user there is (or is not) some string related to dates in or around this area of code, and that's about as far as we can take it."

There is even an ugly slip-up possible with these other tools, such as accidentally converting a program that has already been converted. If it is instructed to change DATE to NEWDATE, you'll see NEWNEWDATE. Or worse, converting the data twice may result in "191997".

And, what if the MOVE A TO B is in a line starting with an asterisk, i.e., a comment line? Convert it? Probably not. What if the previous line says, "Peter, please remember to uncomment the next line before compiling this code." Convert it? Probably should!

The other finder-type products out there purport to having success in finding 50-60% of date-related fields. I remember hearing recently that there are 561 known combinations of date-related strings, like DATE, CALENDAR, MONTH, 1996, 1997, etc. And, not UPDATE, DATA, I LIKE DATES AND FIGS, and other such strings. And, what about German and French and Spanish strings? I think that if we find, record, and report on what the user is looking for, we have a marketable tool. Also important is that we recognize and exclude these "false positives". If our tool allows you to easily state string matching parameters so that we find what you want, and exclude things you don't want, that might be better than a robust, but faulty, product that finds 60%, with 20% being wrong, or false.

We believe that if you are the typical ADABAS/NATURAL site, you will have concerns about cost. The N2O toolbox with its new N2O N2OSCAN feature is in the right price range (and free to existing N2O sites!).

You may want to do conversion of one application at a time, and not "send all code somewhere". With over two years to accomplish the conversion of those applications still needing attention, the simple N2O N2OSCAN feature (plus our other 8-9 "helper products") are just what you need.

You may be concerned about confidentiality of the programs and the data. Keeping your code and data at home is the best way. You can do that with our tools.

Ease of use and flexibility will be an issue. With our tools, no PCs are necessary, no downloading and uploading of data or programs, and maybe no high-priced consultants. Again, this saves you time and money.

Yes, the N2O N2OSCAN is part of N2O. We believe we must put this Superfinder in perspective. It is a string finder (and a rememberer, and a recorder, and a reporter). It fits in the N2O Toolbox as a very powerful, but simple, tool. It should be included in N2O, and in fact has been on the Change/Enhancement list for years, along with some other extensions to the N2O Toolbox.

As the NATURAL 2 Organizer, N2O provides other key parts of the solution. N2O provides the inventory part (to determine which objects are in what libraries), the object management part (to move the appropriate objects from some environment to the Y2K conversion environment), the Project Tracking feature (to keep track of Y2K conversion progress), the source compare tool (to see what code might have been changed), etc. N2O suddenly has even more to separate it from the lesser Change/Management packages out there. In fact, why should other C/M vendors charge extra for a tool to find dates in the source code they purport to manage?

If you have N2O already, you are a winner. If you don't have it, you should get it soon. If you buy it solely for Y2K efforts, you'll save money over the other options. And, you'll be getting a robust Change/Management system along with it.

George Szakach

President