alchemy

Microsoft Offers $60,000 in Azure Services to Startups

Tue, 31 Jan 2012 01:03:00 GMT

The cloud is a fantastic place to incubate a tech startup. There are zero computing infrastructure costs and setup times are nil. And, of course, the cloud offers true elasticity and scalability. That's why Microsoft is offering $60,000 worth of cloud services to startups through their BizSpark Plus program.

Who's eligible? Any member of TechStars, Global Accelerator Network, Seedcamp, Dogpatch Labs and a host of other tech startup organizations.

The cloud just makes sense for startups. Most go from virtually zero web traffic to LA-style gridlock overnight. The Windows Azure cloud effortlessly scales to handle the demand. And it's a lot cheaper than ramping up extra servers.

The platform is also flexible—it works with virtually any programming language and platform, including Java, PHP, .NET node.js.

If that wasn't enough, Microsoft will connect startups with their enterprise and mid-market customers.

This is only the latest BizSpark program. It has been supporting startups for years—and introducing them to .NET and other Microsoft technology, of course. This new Azure program starts today, but won't last forever. The first year of Azure services (up to $60,000) is free. The second year is half-price.

HP Goes Green with Power-Sipping Servers

Mon, 19 Dec 2011 20:19:00 GMT

Data centers are huge, power-hungry and inefficient. They consume electricity and IT budgets at staggering rates. HP wants to change that. The company's enterprise server division is developing efficient, compact machinery that's set to shatter our views of the traditional data center.

The HP Performance Optimized Data Center 240a, or HP EcoPOD, is about 1/10th the size of a traditional data center, and it's portable. The system fits into two 40-foot shipping containers and includes integrated power, cooling, security, fire suppression, management and monitoring suites. The whole thing is built in a factory to customer specs and comes pre assembled. Simply unpack it and plug it together. That means the EcoPOD can be ready to serve up data and crunch numbers within 12 weeks of placing an order with HP. The typical data center takes more than 24 months to get up and running.

Once assembled, the EcoPod is just 45 feet long and 23 feet wide. Despite its diminutive size, the data center can house 44 standard 50-server racks for a total of 2,200 servers with more than 7,000 server nodes. And there's space for 24,000 large-form-factor hard drives, too.

The system comes with two CleanSource flywheel-based UPS systems that can crank out up to 2.3MW, giving users more than enough time to switch to generators if there's an interruption in power.

To keep it all from melting down, the EcoPOD uses Adaptive Cooling. The system pumps in outside air to cool the servers whenever possible and cranks up the A/C to cool things off depending on the environment and server load. Adaptive Cooling can push more than 3800 cubic feet of air over the servers every minute.

The EcoPOD uses half the energy of a typical data center. A data center's efficiency is measured by Power Usage Effectiveness (PUE)—how much of its total power consumption is actually used for computing. A data center with a PUE of 1 would use all of its electricity for computing. A data center with a PUE of 2 would only use half its energy for computing. The EcoPOD has an average PUE between 1.05 and 1.3, depending on server load and cooling system use. Normal data centers only manage a PUE of 2.4.

The EcoPOD is also inexpensive—it costs just $500,000 a year to run. Brick-and-mortar data centers cost nearly 31 times that to run.

The Alchemy NeoTools suite of mainframe migration software runs natively on HP servers.

Sources: HP, Gizmodo

Alchemy Solutions at the 2011 Microsoft BUILD Conference

Tue, 11 Oct 2011 19:32:00 GMT

Alchemy Solutions sent a few of its developers to attend the unveiling of Windows 8 at the 2011 Microsoft BUILD conference in Anaheim California.

The conference concentrated on a brand new runtime (WinRT) and its support for the new Metro touch-first application style. WinRT is a new API rewritten from the kernel up, emphasizing asynchronous methods and patterns throughout to ensure responsiveness. Metro, on the other hand, is a very clean, no-chrome touch-screen interface. At first it appeared to be a bit gimmicky, but as the conference went on it was clear there were many uses for this UI. It’s definitely an improvement over traditional windows when using touch for navigation.

At Alchemy we’ve been discussing ways to simplify user access to NeoBatch Job Monitoring and Reporting services. The Metro UI certainly looks like a great candidate for this task. We are also considering Metro/WinRT advances in NeoKicks and NeoData. And as always, we will try to drive the language improvements in the .NET framework into Fujitsu’s COBOL products.

Microsoft gave us some tablets preloaded with Windows 8 —this was clearly one of the conference highlights. The tablets will allow us to get a jump on laying out how we can integrate our products with Windows 8 and Metro. From our perspective, the conference was a success not only for Microsoft’s Metro UI but for Alchemy as well.

COBOL Warnings – Highlights possible issues you may not have known about.

Fri, 07 Oct 2011 20:56:00 GMT

I had a recent inquiry into why all the warnings in Fujitsu COBOL and why have them, and how could they turn off warnings in not only COBOL, but in other mixed languages. I guess I go back to moments in my life, when I was warned “don’t do that”, and like any kid, I may have not heeded the advice, to my later dismay. Warnings are really your friend. They may seem overwhelming at times, but they may point out important things in your code, that many times you don’t even know existed.

The person with the warnings was coming from another COBOL vendor. As he looked through them, he found spots identifying problems that he had encountered intermittent issues with that he never knew existed before, as the other COBOL vendor did not warn on them. For example, extremely long COMPUTES are warned on, as you may exceed intermediate fields. It does not mean the code will not work, but it brings your attention to the thought that it should be checked, that depending on the values in the compute, you may come up with a different value than you would like, the same as if you wanted to add 99 + 99, and put it in a PIC 99 field. Another one of my favorites is if someone has an IF statement, such as “IF Field1 EQUALS (‘A’ or ‘B’)”, where if you note the parenthesis, it makes you wonder, as parenthesis are resolved first. Fujitsu is solid enough to run like that, but it is better to resolve those warnings. I have found Fujitsu COBOL to be thorough in its checking of the code, and taking the time to resolve warnings many time fixes things you did not even know you had issues with on your prior environment. So, I would take the steps to clean up the the warnings, rather than turn them off.

For my purposes, I have a test “warnings” program, which I will include at the end of this blog. You can see the flow the program is using, and the way the checking is being done. You may copy this code and try it out, to see how the warnings will react, or add your own warnings in. This code is given as is, and it is up to the end recipient to use as they wish.

If you still wish to turn off warnings, under Fujitsu COBOL you can do it with the compiler option “FLAG(x)”, where “x” is the compiler error level you want. For example "FLAG(E)” will only show you critical errors. You can consult the manuals for more compiler option and level information.

The following are screen snapshots of the project properties of where you can modify your compiler options for COBOL, C#, and VB.NET. Under NetCOBOL for .NET, it is part of your compiler options as it is under all of COBOL for Fujitsu. For more information on how to set CSharp or VB.NET Warnings or Error levels, please consult the Microsoft manuals.

(Note: You can double click on a picture to expand it).

COBOL

CSharp

VB.NET

TEST WARNING COBOL PROGRAM:

IDENTIFICATION DIVISION.
PROGRAM-ID. TESTJMWARN.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
REPOSITORY.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-ANY-KEY   PIC X VALUE SPACES.
01 WS-COUNTER   PIC 99 VALUE 0.
* JMN1900I-W: The level-number hierarchy is invalid.
* Note: Data is still visible, and usable.
01 WS-LEVEL-NUMBER-HIERARCHY-INV.
    05 WSF2-3.
    15 WSF2     PIC X(3) VALUE "ABC".
    10 WSF3     PIC X(3) VALUE "DEF".
* JMN2232I-W: The length of the redefining item cannot exceed the length of the redefined item. The redefining item overlaps no items other than ones explicitly specified.
* Note: Implications are that in this case, P-LINE-DATA will not have all 15 characters. I recommend cleaning these up, as the other
*       concern is that your memory mapping may not be as you want it.
01 WS-REDEFINE-A.
    05 P-LINE-DATA   PIC X(10) VALUE "ABCDE12345".
    05 P-LINE-O     REDEFINES P-LINE-DATA.
        10 P-FIELD1 PIC X(5).
        10 P-FIELD2 PIC X(10).
01 WS-REDEFINE-B.
    05 P-LINE-DATB PIC X(15) VALUE SPACES.
    05 P-LINE-OO    REDEFINES P-LINE-DATB.
        10 P-FIELDA PIC X(5).
*JMN2705I-W: The VALUE clause cannot be specified for an item specified in a REDEFINES clause or for its subordinate item. The VALUE clause is ignored.
*Note: P-FIELDB's data will not be placed in P-LINE-DATA at the start of the program - I don't think any compiler will do this.
         10 P-FIELDB PIC X(10) VALUE "0987654321".
* JMN1020I-W - The literal must start in AREA B.
* The above warning is strictly a warning and does not affect the code.
01 SERVICE-D-NOTE-1.
     05 FILLER                  PIC X(13) VALUE SPACES.
     05 FILLER                  PIC X(61) VALUE
"NOTE: FOR 3P3W APPLICATIONS: A NEUTRAL SPACE IS INCLUDED IN ".
01 MYTABLE-SUB   PIC 99.
01 MYTABLE.
     05 MYITEMS    PIC X(2) OCCURS 5 TIMES.
PROCEDURE DIVISION.
*****************************************************************
* BEGIN of JM* Examples...

       PERFORM 1020I-JMN1020I-W THRU 1020I-EXIT.
       PERFORM 1041I-JMN1041I-W THRU 1041I-EXIT.
       PERFORM 1900I-JMN1900I-W THRU 1900I-EXIT.
       PERFORM 2506I-JMN2506I-W THRU 2506I-EXIT.
       PERFORM 2508I-JMN2508I-W THRU 2508I-EXIT.
       PERFORM 2540I-JMN2540I-W.
       PERFORM 2682I-JMN2682I-W THRU 2682I-EXIT.
       MOVE SPACES TO WS-ANY-KEY.
       DISPLAY "PRESS ENTER TO FINISH DEMO" UPON CONSOLE.
       ACCEPT WS-ANY-KEY FROM CONSOLE.
       STOP RUN.
* End of JM* Examples...
*****************************************************************
1020I-JMN1020I-W.
* JMN1020I-W - The literal must start in AREA B(See Working Storage for field in example).
* The above warning is strictly a warning and does not affect the code.
     DISPLAY SERVICE-D-NOTE-1 upon console.
     Accept ws-any-key from console.
1020I-EXIT.
     EXIT.
1041I-JMN1041I-W.
* JMN1041I-W: A separator must follow the character string. A separator after the
* character string is assumed.
* logic still works OK
     DISPLAY "ENTER A 'J' " UPON CONSOLE
     ACCEPT WS-ANY-KEY      FROM CONSOLE.
     IF WS-ANY-KEY="J"
        DISPLAY "You selected J" Upon CONSOLE
     ELSE
        DISPLAY "'J' NOT ENTERED " UPON CONSOLE.
     DISPLAY "ENTER TO CONTINUE " UPON CONSOLE.
     ACCEPT WS-ANY-KEY            FROM CONSOLE.
1041I-EXIT.
     EXIT.

1900I-JMN1900I-W.
* JMN1900I-W: The level-number hierarchy is invalid.
* Note: Data is still visible, and usable.
     DISPLAY "WS-LEVEL-NUMBER-HIERARCHY-INV ",
             WS-LEVEL-NUMBER-HIERARCHY-INV UPON CONSOLE.
1900I-EXIT.
       EXIT.

2506I-JMN2506I-W.
* JMN2506I-W: A statement must be specified in a conditional statement or an in-line PERFORM statement. It is accepted as written.
       MOVE SPACES TO MYITEMS(1), MYITEMS(2), MYITEMS(3)
                       MYITEMS(4), MYITEMS(5).
       MOVE "AA"    TO MYITEMS(1), MYITEMS(2), MYITEMS(3).
       PERFORM VARYING MYTABLE-SUB FROM 5 BY -1
         UNTIL MYITEMS(MYTABLE-SUB) NOT = SPACE
       END-PERFORM
2506I-EXIT.
      EXIT.

2508I-JMN2508I-W.
* JMN2508I-W 450 NEXT SENTENCE cannot be specified in an IF or SEARCH statement with an
* explicit scope terminator. It is accepted as written.
      MOVE SPACES TO WS-ANY-KEY.
      IF WS-ANY-KEY = ' '
         IF WS-ANY-KEY = 'A' OR 'B' OR ' '
            NEXT SENTENCE
         ELSE
            DISPLAY "JMN2508I-W TEST IN ELSE AFTER NEXT SENT"
                                              UPON CONSOLE
         END-IF
         DISPLAY "JMN2508I-W TEST AFTER END-IF" UPON CONSOLE
      ELSE
         DISPLAY "JMN2508I-W TEST AFTER FINAL ELSE" UPON CONSOLE.

       DISPLAY "JMN2508I-W TEST END" UPON CONSOLE.
       ACCEPT WS-ANY-KEY FROM CONSOLE.
       MOVE SPACES TO WS-ANY-KEY.
2508I-EXIT.
      EXIT.
2540I-JMN2540I-W.
* JMN2540I-W The paragraph containing the EXIT statement can only consist of the procedure-name and the
* EXIT statement itself. The EXIT statement is considered to be a CONTINUE statement in this context.
      MOVE 0 TO WS-COUNTER.
      PERFORM 2540I-COUNT-LOOP 3 TIMES.
      IF WS-COUNTER > 1
         MOVE 12 TO WS-COUNTER
      END-IF
      DISPLAY "2540I-JMN2540I-W AFTER PERFORM LOOP "
                               UPON CONSOLE
      EXIT.
2540I-COUNT-LOOP.
     COMPUTE WS-COUNTER = WS-COUNTER + 1
     DISPLAY "2540I-COUNT-LOOP " UPON CONSOLE
2540I-FELL-THRU.
     DISPLAY "2540I-FELL-THRU " UPON CONSOLE.
* Try to get a clean exit by adding an EXIT here after demonstration.
* Note: to fix problem, try adding a clean exit at the point you wish to exit,
*       and possibly make it a perform through...
2540I-CLEAN-EXIT.
     EXIT.
2682I-JMN2682I-W.
* JMN2682I-W: A parenthesis cannot be specified in an abbreviated combined relation condition. The parenthesis is assumed to be valid.
     IF WS-ANY-KEY = ('A' OR 'B' OR ' ')
        DISPLAY "JMN2682I-W parenthesis still OK " upon console
     else
        DISPLAY "JMN2682I-W parenthesis Not OK " upon console
     End-if.
2682I-EXIT.
      EXIT.
END PROGRAM TESTJMWARN.

Comparing ADO.NET and ODBC for embedded SQL

Fri, 07 Oct 2011 18:53:00 GMT

When new users approach NetCOBOL for .NET and are using embedded SQL in their COBOL code, one question we often get is whether to use ODBC or ADO.NET as the database access mechanism. NetCOBOL for .NET supports both and the good news is that choosing between the two can be as simple as changing configuration settings in your application’s configuration file (usually with the help of the NetCOBOL for .NET provided Runtime Environment Setup Utility). This is because the NetCOBOL compiler and runtime are responsible for handling all the work of translating your embedded SQL queries into calls that are made to the database that you specify.

So why have two different access mechanisms? The answer is that the two access mechanisms do behave differently. The simplest way I can think to distill the difference is to say that ODBC provides a feature set that supports common COBOL programming behaviors better, but ADO.NET can in some cases yield better performance. For new users, I would recommend that you start by using ODBC and then when you are looking to tune the performance of your application, you try testing with ADO.NET to see if a) you aren’t affected by the feature limitations of using ADO.NET and b) you actually get a performance benefit from using it.

The rest of this blog post will try to give you some more specifics about how the two access mechanisms differ. The fundamental reason for most of the feature limitations in ADO.NET stems from the fact that ADO.NET does not support server side cursors. COBOL applications tend to use lots of cursors so what’s a COBOL runtime to do? The answer is that the NetCOBOL runtime emulates needed cursor behavior using client side cursors. There simply isn’t a way, however, to get the same database consistency mechanisms with client side cursors that you can get with server side cursors, so only optimistic concurrency is supported with ADO.NET.

If you are going to try to use ADO.NET, you will definitely want to read through the “Notes on Using ADO.NET” topic found in the NetCOBOL for .NET User’s Guide. It provides you with a long list of feature limitations that exist when using ADO.NET as the access mechanism, many of which are the upshot of not having server side cursor support.

So, now to the good parts of using ADO.NET. The most important point is really that Microsoft has invested a lot in making the ADO.NET data access drivers perform very well and this can result in better performance for COBOL applications as well. Note, however, that this is not universally the case. If you have an application that uses updatable cursors that select large numbers of rows, but only read a few, ADO.NET will perform poorly and consume lots of memory. This is again because a lot more data is going to be loaded on the client side rather than just using a server side cursor.

Another reason why ADO.NET may be a better choice is due to transaction integration. With ADO.NET, the data access driver uses what is sometimes referred to as a lightweight transaction manager that can manage multiple coordinated transactions within an application without being promoted to a heavyweight transaction that has to be managed by Microsoft’s Distributed Transaction Coordinator (DTC). If you aren’t coordinating transactions between your COBOL code and other parts of your application, then this won’t affect you, but heavyweight distributed transactions perform orders of magnitude slower than lightweight transactions, which can be a significant consideration if you are using them.

NeoData / SQL Server Profiler - Trace results from SQL Server

Mon, 14 Nov 2011 23:25:00 GMT

Have you ever wanted to see what Microsoft SQL Server sees while your application runs? You can log/trace SQL Server events while the NeoData engine interacts with COBOL dynamically converting your ISAM instructionsto SQL Server context. As a matter of fact, all interactions to your SQL Server database, including your ESQL are viewable through the SQL Server Profiler.

If you are trying to debug your NeoData application, it is suggested to use the NeoData Trace log feature first, to which you can find an earlier blog on that topic as well.

You can do additional information gathering, by using a Microsoft SQL Server tool called "SQL Server Profiler". It shows you the syntax of the SQL Server Instructions and problems found. It helped me find out that I had inadvertently copied a table under SQL Server and that SQL Server cannot have two tables with the same index name, in the same Database!

Microsoft SQL Server Profiler is a graphical interface to SQL Trace for monitoring your Database transactions. SQL Server Profiler shows how SQL Server resolves queries internally. You can record and save information about these transactions through the Profiler to a file or table to view
after the application completes. You can create a template (.tdf) file that you can use when you want to trace.

The purpose of this blog is to give a starting point into SQL Server Profiler, to assist you. If you have questions about details of SQL Server, you’ll need to go to the usual sources of SQL Server assistance such as the help files, MSDN or other Microsoft support channels.

Like any tracing, SQL Server Profiler takes additional resources when running, and tracing should only be used when necessary, as it will have some impact on your application, depending on use.

Steps under SQL Server 2008 to create a TRACE file. (At the end of this blog are screen snapshots of the tool in use).
- connect to SQL Server by logging in.
- Go to the Tools menu - Select SQL Server Profiler.
- Log Back in again, at the log-in prompt to get you into the profiler.
- At this point you are brought to the Trace Properties screen, where you can set up if you want to record to a file(.trc), to a database table, or neither or both. The system tells you where it is going to store the table. For my run it was in the “System.database.master.tables (then I named the table dbo.traceExample).

To open a SQL Server Trace File, you can go into the SQL Server Profiler and open it, or under Windows Explorer, right click on the ".trc" file, select "Open With", select "SQL Trace Tool".

You can copy the text from your SQL Statement from the trace, then go into SQL Server and paste the copied query into Query Execute box, and see the results or the error.

Additional Links you may wish to reference :
http://msdn.microsoft.com/en-us/library/ms181091.aspx (High Level Description)
http://msdn.microsoft.com/en-us/library/ms187929.aspx (Additonal how to use detail)

Screen Shots of the SQL Server Profiler tool in action.

Step 1. Log into SQL Server Management Studio.

(normal log in).

Step 2. Select the SQL Server Profiler Tool:

Step 3: Log into the SQL Server Profiler tool (screen looks very much like the Management Studio log-in).

Step 3: Set up the parameters of how you wish to run the profiler. Enter the properties, press the run button at the bottom. The snapshot is meant to let you know that you are on the right screen. On this screen, you can set up if you wish to record to a trace file, as described earlier. You can specify what events you wish to use on the other tab. You can save the entries into a table in SQL Server as well!

Step 4 – View your output. At this point, you can start your application if not already started. Below is what the screen will look like while you are running.

NeoData Log/Trace File creation

Fri, 07 Oct 2011 18:56:00 GMT

Did you know that you can debug the NeoData events that occur while your program is running, by updating your App.Config file that is associated with the Executable/solution or project you are running? This information is valuable in tracing the events that are happening in your COBOL program interacting with NeoData.

There are two different types of logging you can do, but the first one, going to a file is strongly recommended, especially if you wish to send the information off to Support. The second one is writing to your Event Log, and will only be touched upon briefly.

The NeoData Help does a very nice job of covering the set-up of the trace logging and should be read in conjunction to this blog article.

This blog contains the following items:

* Set-up example of your NeoData Config File for writing to a trace log
* Sample output of the different levels of tracing you can turn on
* Sample full App.config file.

Set-up Example/Instructions for setting up a trace/log of your NEOData Events using your Config File

* Open up your App.Config file which is part of your solution that contains your COBOL programs.

* Go to the System Diagnostics section and you can copy/paste into the App.Config file the following:
Optionally change the Tracing level, path/file name to log to, listener name/type of listener, but, it should work just as is. You will need to change where you want the log stored(Look for “C:\MyData” as the folder, and change to your location. Be careful not to overlay existing code you may need:

<system.diagnostics>



<switches>
<add name="NeoDataTraceSwitch" value="4" /> <!— **Optionally Change **-->
</switches>


<trace autoflush="true">
<listeners>
<add name="TestTracer" <!— **Optionally Change **-->
type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="C:\MyData\NeoDataTrace.log" /> <!— **Change Folder Location **-->
</listeners>
</trace>

</system.diagnostics>

* Optionally set the NeoData Trace Switching (1-4) described below as you need them.

* Optionally change the listener name.

* Specify the type of “Systems.Diagnostics” Event logging you wish to do, being either TextWriterTraceListener (recommended strongly), or EventLogTraceListener (which goes to your Event Log).

You can point to a file location that you wish to write to, by using the “initializeData” field, and either giving a relative path, with just a file name, or specifying a full path as in the example contained in this blog(Shows C:\MyData\NeoDataTrace.log").

You have four levels of output that you can do based on the NeoDataTraceSwitch.

They are 1= Errors Only, 2=warnings also, 3=info also, 4=verbose.

(1) only gives you errors that have happened,

(2) thru (4) successively give you more information.

The higher the level you set the more data is generated, so the larger the file, the greater the impact to the application. If you run with a high level in a long application, your file will be very large, and it may noticeably impact performance. For this reason, only use the setting you need for the time you want to trace what is happening in your application in conjunction with NEOData. The sample output file shows the output that is generated depending on the NeoDataTraceSwitch level set (1,4)

Sample NEOData Log File Output

** With a 1 on.. errors only, (note – no errors, so nothing shown)

** With a 2 On...warnings also (note – simple message showing DataMapper startup)

NdInfo: 2011-02-11T15:36:59: DataMapper static startup beginning

** with a 3 on... warnings and info.

NDFullCycleReadOnlyTest.exe Information: 0 : NdInfo: NeoData Runtime Version: 2.0.10.0

NdInfo: 2011-02-11T15:38:17: Attempting to open Data Map C:\Alchemy\DocumentationAndSamplesWIP\NEODataFullCycle\NDFCYCLE.ndp

NdInfo: 2011-02-11T15:38:17: DataMapper static startup beginning

NdInfo: 2011-02-11T15:38:17: Successfully opened and deserialized Data Map C:\Alchemy\DocumentationAndSamplesWIP\NEODataFullCycle\NDFCYCLE.ndp

NDFullCycleReadOnlyTest.exe Information: 0 : NdInfo: Map Version: 2.0.6.0

NdInfo: 2011-02-11T15:38:17: WindowedTableMgr instantiating, with local AllowsBulkCopy=True

NdInfo: 2011-02-11T15:38:17: Successfully restored dependencies for Data Map

NdInfo: 2011-02-11T15:38:17: Successfully opened file

** With a 4 on ... verbose (the most information).

NDFullCycleReadOnlyTest.exe Information: 0 : NdInfo: NeoData Runtime Version: 2.0.10.0

NdInfo: 2011-02-11T15:41:15: Attempting to open Data Map C:\Alchemy\DocumentationAndSamplesWIP\NEODataFullCycle\NDFCYCLE.ndp

NdInfo: 2011-02-11T15:41:15: DataMapper static startup beginning

NdInfo: 2011-02-11T15:41:15: DataMapper instantiating, with Global AllowsBulkCopy=True

NdInfo: 2011-02-11T15:41:15: DataMapper static startup ending

NdInfo: 2011-02-11T15:41:16: Successfully opened and deserialized Data Map C:\Alchemy\DocumentationAndSamplesWIP\NEODataFullCycle\NDFCYCLE.ndp

NDFullCycleReadOnlyTest.exe Information: 0 : NdInfo: Map Version: 2.0.6.0

NdInfo: 2011-02-11T15:41:16: WindowedTableMgr instantiating, with local AllowsBulkCopy=True

NdInfo: 2011-02-11T15:41:16: Successfully restored dependencies for Data Map

NdInfo: 2011-02-11T15:41:16: Successfully opened file

NdInfo: 2011-02-11T15:41:18: Comparing the next two lines for equality: result True

Src: 30303332

Dst: 30303332

Sample: App.Config

Please note, if you use code from this App.config file, you will need to change at a minimum, the “C:\MyData”, to a folder location on your system, or create a folder called “C:\MyData”.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

<system.diagnostics>



<switches>
<add name="NeoDataTraceSwitch" value="4" />
</switches>


<trace autoflush="true">
<listeners>
<add name="TestTracer"
type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="C:\MyData\NeoDataTrace.log" />
</listeners>
</trace>

</system.diagnostics>

<fujitsu.cobol>
<runtime>
<environmentSettings>
<add key="@CBR_EXFH_API" value="VDBFileHandler" />
<add key="@CBR_EXFH_LOAD" value="C:\Program Files\Alchemy Solutions\NeoData V2\V2\VDBFH.dll " />
<add key="GOODFILE" value="C:\MyData\NDFCYCLE.ndp,EXFH" />
<add key="GOODFILE_IDX" value="C:\MyData\GOODFILE" />

</environmentSettings>
</runtime>
</fujitsu.cobol>
</configuration>

Set Project Output Path, so all projects run from same folder.

Mon, 14 Nov 2011 23:32:00 GMT

Are you encountering the situation where you wish that rather than adding references to other projects or DLL’s, in order to bring them into your bin directory, that you could simply specify that all your programs went into the same folder? The simplest way to run applications under .NET is to have them all in the same folder. This typically, while debugging is in the debug\bin folder. This may also mean that you are finding yourself placing other dependant DLL’s in the same folder. One easy solution is to change your Output Path in your project, and other projects that share DLL's. You get there by selecting “Project Properties”, then the “Build” tab, then setting the OutPut Path. Setting the output path to where you keep all your programs, will allow them to be found, as this is the path this Solution/project will run from and expect to find it’s program it needs.

Should You Pay for COBOL Runtimes?

Mon, 14 Nov 2011 23:34:00 GMT

Having established in my previous blog what “COBOL runtimes” are, in this blog I’ll consider whether you should pay for COBOL runtime licenses – i.e. the right to ship and use COBOL runtime libraries with your applications.

After establishing what we should, or might, pay for, I’ll approach the subject of runtime charges by explaining some of the history of COBOL runtimes which established a model for COBOL runtime charges and then discuss what is a reasonable model today.

Assumption: We Pay for Added Value

Generally speaking we pay for goods and services that add value to our lives or company operations. If you don’t believe an item adds value you won’t pay for it – or will pay grudgingly if you are not given a choice which, for example, is how many people view taxes.

When you buy a COBOL compiler you expect it to compile your COBOL programs and give you code that will execute. If there was no COBOL runtime library, you would take that code and execute it on any computer that supported that code and would clearly need no license to do that. However, there is a COBOL runtime library that needs to be shipped, so does that add value worth paying for? Or is it a component that just supports your COBOL code so is only delivering the functionality you paid for when you purchased the COBOL compiler?

A look at COBOL runtime history will give us some insights into perceived value for COBOL runtimes through the years.

COBOL Runtime History

Space – The First Frontier

The issue of COBOL runtime licenses really surfaced with the advent of computers with microprocessors where it became possible to develop and compile programs on one computer but execute them on many other computers. The initial microcomputers, and later PCs, that were available from the mid ‘70s to the mid ‘80s didn’t have a lot of memory - 16KB was standard on the initial IBM PC introduced in 1981, with 640KB forming an upper bound for several years after that. It was a pretty challenging feat to execute COBOL programs in that amount of memory, particularly large applications that involved large data divisions and many modules. Creating a COBOL compiler wasn’t just a matter of turning the COBOL statements into executable code, the compiler vendors also had to provide the means of switching code in and out of memory as you couldn’t have everything in there at once. Thus the COBOL runtime wasn’t just providing subroutines to support the execution of COBOL statements, it was providing a virtual operating environment in which the compiled COBOL programs would execute.

Early COBOL vendors could therefore argue that when you used their COBOL runtime library on another computer you were using a specialized operating environment developed by them to allow your COBOL programs to execute. Without this environment your programs wouldn’t fit – the operating systems of those days wouldn’t be able to cope with the loads.

A reasonable case for added value.

Reaching Beyond COBOL

An ongoing challenge for COBOL compiler creators was (and is) that the COBOL standard (a generally accepted definition of COBOL) develops slowly but the wishes of those using COBOL compilers develop at least as quickly as their understanding of what is possible on the current operating platform (i.e. much faster than the standard). COBOL vendors would therefore add the ability to do things that went beyond standard COBOL. Some of the abilities were provided by extensions to the language, such as extensions to the DISPLAY statement to display data on a full screen rather than single lines being relayed to a terminal, and others were provided by adding subroutines to the COBOL runtime library – i.e. routines you invoked directly, and not just routines the compiler was invoking under the covers to support a COBOL statement.

Where the additional functionality was provided as additional subroutines, there was again a reasonable case for the COBOL runtime library adding value wherever it was installed.

Cross-Platform Environment

ISVs (Independent Software Vendors) create software to sell to others. For business applications many of them have chosen COBOL because it is supported across many different platforms. As long as they stick to a standard that is supported across platforms these software companies can write their applications once and deliver them on many different computers – a good business move as you can’t always determine which types of computer your potential customers will purchase.

Several COBOL vendors designed their compilers so that they generated an intermediate code that was not targeted at any particular machine. Their runtime libraries were actually runtime environments that created virtual computers that executed the intermediate code. Provided the vendor developed a runtime environment for a particular computer, you could compile your COBOL programs once and run the code on any of the supported computers.

Providing an execution environment was a reasonable added value.

Cash Cow for Vendors

Of course, any COBOL compiler vendor that has charged for use of its COBOL runtimes now has quite a nice cash flow as applications continue to be written and distributed that rely on those runtimes. This can be really nice for the vendors but painful to the customers if the perceived added value has diminished.

Today’s Perspective on Historical Added Value

Now that “micro computers” are no longer small, operating systems for those environments have advanced well beyond the additional capabilities offered by COBOL compiler vendors and the historical justifications for COBOL runtimes providing added value have weakened:

1. Memory management – fitting a lot into a small space
Today memory is plentiful and operating systems handle memory management well. It no longer makes sense for COBOL compiler vendors to insert their own layer of memory management on top of the operating system. Even if they do it is difficult to argue that they are providing added value.
2. Reaching beyond COBOL – providing additional abilities
While micro-processor operating systems were young there were many obvious functions that business programs needed and adding them to the COBOL environment was the only way a COBOL compiler vendor could make the functions available to their customers. With well-developed operating systems everything a user wants is provided and each new release provides abilities beyond what the user might have imagined. The task for COBOL (or other language) compilers is to make all operating-system-provided functions available as quickly as possible. The best way to do that is to get out of the way by providing direct access to operating system functions – for example by integrating well with the .NET Framework.
COBOL runtime libraries have little opportunity for providing added value.
3. Cross-Platform Environment
The need for a cross-platform environment is greatly reduced today compared to 10 or 20 years ago when there were many more possible target environments. It is quite viable for ISVs to target a single platform such as Windows because the market of Windows users is quite big enough for most companies’ ambitions. Also, performance expectations often mean that providing a virtual environment for executing intermediate code results in poorer performance than available with code that is compiled for a specific platform. Even if you create intermediate code your compiler vendor may provide you with an additional pre-execution step to change that code to the object code for the target platform. The runtime environment is no longer giving the added value of a portable virtual computer.

The Added Value Trap

Any company that saw the added value of the COBOL runtimes offered by a compiler vendor and chose to take advantage of that added value may now find themselves in a trap. The trap can work in two ways:

1. The added value has diminished or disappeared (as in the case of the COBOL runtime providing memory management) but the COBOL runtime charges remain. The functionality is available elsewhere free but there’s a sizeable cost in converting your applications to use that free model.
2. Whether or not the added value remains, the company has invested years of development effort in creating code that depends on the COBOL runtime environment. The cost of converting to another environment is so high that the compiler vendor can increase their COBOL runtime charges almost at will. Although the initial price of the runtime charge was considered a good investment for the added value provided, that is no longer the case.

Conclusion – Only Pay for COBOL Runtimes IF:
You HAVE to have the added value offered
AND are willing to deal with the added-value trap
OR are confident you have an iron-clad escape plan

Free Runtime Philosophy and Benefits

NetCOBOL compilers have been created with the following principles:

* Generate code that works seamlessly with the operating environment
* Give the programmer direct access to operating-system functions - do not insert run-time layers between the COBOL program and the operating system
* Only extend the COBOL language when required to make COBOL programs work seamlessly with the target environment (such as the .NET Framework)

Consequently the NetCOBOL runtime libraries are primarily there to support the compilation and execution of the COBOL syntax. This makes it easy for Alchemy Solutions to provide the runtime licenses for free and not place that additional financial burden on their NetCOBOL customers.

The compiler development philosophy also means that users of NetCOBOL compilers can usually take advantage of new functionality in the operating system as soon as it is available – they don’t have to wait for Fujitsu to develop COBOL-specific support for that functionality as can be the case if most operating system interactions have to go through a COBOL runtime layer.

If you think this philosophy makes sense, check out the NetCOBOL family of compilers or pick the brains of one of our reps who have a good understanding of most COBOL compiler-related issues and questions.

Creating your own NeoBatch SQL Reports in VS2010

Mon, 14 Nov 2011 23:34:00 GMT

With the release of Visual Studio 2010 and SQL Server 2008 R2, the way reports were being done for VS2008 has been changed and such we need to change the way we create our NeoBatch reports.

I’ll do a quick walkthrough of how to create a simple report for NeoBatch

Creating the Project

1. Start up Visual Studio 2010

2. Go to File –> New Web Site, Select Visual C# and choose ASP.NET Reports Web Site, Click OK.

3. Visual Studio should start up the Report Wizard, Configure your connection to your NeoBatch SQL Database, Click Next, Save the Connection if you want.

4. Choose your database objects, for this simple chart we are just going to select the jobs table from our NeoBatch Database.

5. Click Finish, and then cancel to quit the wizard.

The Wizard should quit and leave you with a project with the database connection but no chart created.

Configuring your DataSet

1. DoubleClick on the NeoBatchDataSet.xsd file in the solution explorer

2. Select the TableAdapter control and drag it from the tool box onto the main window.

3. This should open the Table Adapter Configuration Wizard. Select the NeoBatchConnection String created when the project was created.

4. Select the “Use SQL statements” option.

5. Add the following SQL Query:

SELECT TOP 10 [job].[name] , SUM(S.CpuTime) as TotalCpu FROM JOB INNER JOIN Step S on S.JobId = Job.JobId GROUP BY Job.Name ORDER BY SUM(S.CpuTime) DESC

Click Finish.

6. Rename the TableAdapter to Durations.

Creating your Chart

For this quick example we are going to make a chart that displays the durations of the jobs which have been run in NeoBatch.

This is similar to a report found in the VS 2008 Reports

1. Right click on the black report and select the Insert –> Chart Optionimage

2. For this example we are going to do a simple column graph. The first one in the upper left had part of the screen.

Click OK, Select your Dataset you created when creating the project and click ok again, It should then drop a chart onto your report page.

3. Right click on the NeoBatchDataSet under report data on the left side of visual studio and select “Add DataSet…”

Name the new DataSet, “DurationSet” and select the Durations Dataset and click ok.

4. Drag the name value to the category fields on the bottom, and TotalCpu to the data fields section on the top.

5. Right click on the Y- Axis on the left part of the chart, and select “Axis Properties”. Click on the number section and change the value from Default to Number. Click OK.

Do the same for the X-Axis, however for this axis under Axis Options, change the interval to 1.

6. Select Default.aspx, Click on the arrow in the upper right hand corner, this will open the ReportViewer Tasks. Select choose DataSources. For DurationSet select ObjectDataSource2.

7. Running the project should now display a report:

8. From here you can clean up the report, rename a few things, and have a fairly decent looking report. Open-mouthed smile

Questions? Thoughts? Comments?

Diagnosing a Resource Leak

Mon, 14 Nov 2011 23:36:00 GMT

We had a customer report an issue with their NeoKicks converted application, where NeoData was apparently exhausting pooled SQL connections. It certainly seemed odd, given the fact that their load was relatively low. To help us debug, we had them create a crash dump of IIS using the Debug Diagnostic Tool from Microsoft.

Once I got a crash dump, I fired up Windbg, attached to the crash dump, and loaded SOS by issuing:

.loadby sos mscorwks

Since this is a .NET solution and the error was related to running out of pooled connections, I could dump the objects with references (that the GC won’t collect) using !dumpheap.

Glancing through the output, I found the following:

The highlighted number above is the count of the object for each type. The reason this one in particular is odd is that the WorkerSession object represents a current, running transaction. The WorkerSession object contains things like open file handles, etc. If there are 525 active transactions with each containing a few NeoData files, then it is certainly possible the SQL connection pool is exhausted. Since this server wasn’t under a lot of load (just had been running for a while), 525 seems way too high. I would expect this to be in the 1-10 range. Luckily, we can dig in a little deeper to see who has a reference to these objects in Windbg.

The next step is to get more information about each one of these objects. You can use:

!dumpheap -type Alchemy.NeoKicks.WorkerSession

to dump out the references to that object type.

I’ve highlighted the address for one of the objects in the listing from !dumpheap. I just picked one at random. I want to find out what has references to this object, to see what might be preventing this object from being garbage collected. To do this, I use the following:

!gcroot 000000016fa53470

I looked at a few other objects (again, using !gcroot) and found that they were all being ultimately held by a System.Threading._TimerCallback object.

This was getting interesting! Why in the world would a TimerCallback object have a reference to my WorkerSession object? I decided it was time to go looking through our NeoKicks code to see where a TimerCallback was used. It turns out, a WorkerSession object can contain a Timer object that is used when a CICS START is issued so that the transaction will execute on a thread pool thread (and optionally on a time interval). These objects should have gotten cleaned up by the GC, since these tasks run immediately and return.

I decided to look through the documentation for Timer objects in the MSDN documentation and found the following:

“When a timer is no longer needed, use the Dispose method to free the resources held by the timer.”

Now we’re getting somewhere. Sure enough, although we implement IDisposable for the WorkerSession object, we were not calling Dispose on the Timer object. I added the Dispose() call, and re-ran a test that reproduced the problem and the issue went away.

The moral of this story – if you are using System.Threading.Timer objects in your code, you must call Dispose() on the object when you’re done. Otherwise, you will end up with a memory leak!

Querying Census Data

Mon, 14 Nov 2011 23:37:00 GMT

I was building a tool to generate some random data for testing with the goal that the data is readable. I wanted to get actual city/state/zip code information so I began looking at the census.gov website for the type of data that is available. I stumbled across several “names files” that contain first and last names and their frequency. The last name file was about 2MB in size – perfect for generating some random customer names.

I opened the file in notepad and started looking through the file to find how common my last name is in comparison to others. Sure, the Find… feature in notepad works – but a SQL query would be better at pulling out the data that I wanted.

Since the format of the file was fixed record size (not comma or tab delimited), I realized that the easiest solution would be to use NeoData to create a map for the fields in the file and import directly into a SQL server table.

Each record contains a record like this:

01 NAME-RECORD.
05 NAME PIC X(15).
05 FREQ PIC 9.999.
05 FILLER PIC X.
05 CUM-FREQ PIC ZZ.999.
05 FILLER PIC X(2).
05 RANK PIC 9(5).

So I fired up NeoData and created a sequential file mapping using the COBOL description above, and added a line sequential endpoint pointing to the dist.all.txt file.

Next, I created a SQL mapping with the name field set as the primary key (since it is unique in this file) and added a SQL Endpoint to point to a test database:

Now it is just a matter of running the converter, to convert from the line sequential input to the SQL database:

I now have 88,799 records in my SQL table! Now for the fun part – fire up SQL Management studio and run some queries. I wanted to see how some of the names of my coworkers compare to each other. I used the following query:

SELECT [NAME]
,[FREQ]
,[CUM-FREQ]
,[RANK]
FROM [VidRent].[dbo].[NAME-RECORD]
WHERE [NAME] IN ( 'HOLLIS', 'ANDERSON', 'COOK', 'PAULSON', 'ROBSON', 'LANGER' )
ORDER BY [RANK] ASC

And it gave me the following results:

It turned out to be a trivial exercise to map this Census data into SQL Server using the data conversion feature in NeoData, and now the data is in a form that is easy to consume for my data generator. So when you have a text file that can easily be described with a COBOL record, you can easily convert it into SQL Server using NeoData following steps similar to these.

Why COBOL Runtimes?

Mon, 14 Nov 2011 23:41:00 GMT

You may notice that we make a big thing on our website about the fact that the “runtimes” with NetCOBOL are free so you may well be asking “What are COBOL runtimes and why are they necessary?” I’ll aim to answer the two questions in this post.

If you’ve done any programming, you should be aware that a compiler takes your program that is written in some human-readable form and converts it to code that can be executed by the computer. (Actually the code produced by the compiler is rarely ready to execute immediately – it typically needs some further processing, but those are details that are not relevant to the runtime issue.) For very simple programs a compiler could generate the machine code that implements the statements coded. However, for complex languages like COBOL and complex programs, there is more going on than the COBOL compiler can reasonably handle by converting every line into the precise machine code that would be a match for the statements.

A COBOL Compiler Example

For example, suppose we have the following COBOL statement:
ADD A TO B GIVING C

The COBOL compiler has to be able to handle multiple combinations of items A, B and C. The items can have different types (e.g. BINARY, PACKED-DECIMAL, DISPLAY), different numbers of digits, different placements of decimal points, and different sign storage methods. They may be stored in different areas such as WORKING-STORAGE, the FILE-SECTION, or the LINKAGE SECTION. They may be items that are shared with other programs executing at the same time. Because of the many different possible combinations it rarely makes sense for the COBOL compiler to attempt to generate code that deals precisely with every item, rather it is more likely to generate code like this:

* Call a routine to fetch an item of type A and put it in a common format
* Call a routine to fetch an item of type B and put it in a common format
* Call a routine that will add these two numbers together and return the result in the common format
* Call a routine to put the result in the format required for item C and store it in the appropriate location

Even for a simple statement like the above addition we may have four or more subroutines required to produce the result. All these routines are provided in modules that are linked with the compiled code and form part of what we call the “COBOL runtime”. Without these routines the compiled code wouldn’t work – if you were able to execute it, it would just come back with a long stream of “subroutine not found” errors.

Greater Complexity Enlarges COBOL Runtime Requirement

To the routines required to execute statements you then have to add functions to support everything else that allows a program to exist in today’s operating environments such as:

* Loading the code into the right area of memory with the right permissions
* Reading and writing files
* Printing data
* Interfacing with a graphical environment

* Providing a means for programs to be debugged

Runtime Library, Runtime Licenses and “Runtimes”

All these different requirements add up to the code you write depending upon a fairly large library of routines that are called when the program executes, i.e. at “run time”. The library of routines is therefore called the “runtime library” and you need to ship it with your applications.

Because you are shipping software created by someone else (companies like Fujitsu and Alchemy Solutions) you usually need a license to do that and this is called a “runtime license”. Depending on the context when you see the term “COBOL runtimes” it either refers to the runtime library, if referring to what you ship, or the license (a legal document) that gives you the right to ship the runtime library.

Why NetCOBOL Delivers Quality and Reliability

Mon, 14 Nov 2011 23:40:00 GMT

I recently recalled that I wrote the article below in 2003 for a technical publication but I don’t think it ever saw the light of day. It still contains a number of relevant points that those interested in developing quality code or owning a quality COBOL compiler may find useful, so I’m making the article available here. It is based on an interview with Mr. Masaaki Uchida, at that time General Manager of the compiler development group at Fujitsu in Japan, and adds points derived from other research available at the time.

Check out the article if any of the following interest you:

How Fujitsu builds reliability into the NetCOBOL family of COBOL compilers
What it takes to build high quality software
Insights into Japanese software development
Using tools to boost code quality
Comparing traditional development methodologies with open source methodologies

Use the bookmarks to jump to the parts of most interest to you, as it is a longish article!

NetCOBOL for Linux – A Mix of Japanese and Open Quality

NeoBatch SQL Reports and you

Mon, 14 Nov 2011 23:40:00 GMT

Picture this: You are an active NeoBatch user, you are constantly running jobs working with your JCL batch operations, day in and day out. After making some changes to your JCL, you notice that it’s slowed down a bit. After some more changes, you think you have it going faster again, but you start to wonder: Is there a way to look at the history of the jobs that you’ve run, and present them in a graph or chart? The answer is yes, there is. You’re looking for NeoBatch SQL Reports.

What are SQL Reports

SQL Server Reporting Services (SSRS) is a part of Microsoft SQL Server which is capable of generating a variety of interactive and printed reports. SSRS competes with Crystal Reports and other business intelligence tools, and is included in Developer, Standard, and Enterprise editions of Microsoft SQL Server as an install option.Reports are defined in Report Definition Language (RDL), an XML markup language. Reports can be designed using recent versions of Microsoft Visual Studio, with the included Business Intelligence Projects plug-in installed or with the included Report Builder, a simplified tool that does not offer all the functionality of Visual Studio. Reports defined by RDL can be generated in a variety of formats including Excel, PDF, CSV, XML, TIFF (and other image formats), and HTML Web Archive. SQL Server 2008 SSRS can also prepare reports in Microsoft Word (DOC) format. Simply put, SQL reports are fairly easy to create and allow you to show off the data in your SQL database visually, quickly and efficiently.

SQL Reports and NeoBatch

Alchemy Solutions has developed SQL reports which work with SSRS to display data about NeoBatch jobs you have run either on your local system or on a NeoBatch Server installation.

The current version of NeoBatch SQL Reports requires SQL Server 2008 and Visual Studio 2008. You also need to have SSRS installed and setup correctly. This article assumes you have done this.

Take a few moments to browse through the reports provided with NeoBatch, and envision the possibilities.

Running the Reports

The steps below provide general guidelines for generating NeoBatch SQL reports. See Exercise 14 of the NeoBatch documentation for more details.

Step 1: Generate some data.

You need to have some data in your NeoBatch database in order to generate reports on that data. Data associated with multiple days will help, since some of the graphics are displayed with a timeline.

Step 2: Launch the NeoBatch SQL reports.

To find the NeoBatch SQL reports, head to your NeoBatch install directory. Once there, click on the samples directory, and then the SQLReports folder, and start up the NeoBatchSQLReports solution.

If your database is not on your local system, you may need to change the Data Source in the reports. This can be accomplished by right-clicking on the Data Source for the report and changing the connection string appropriately. By default, it is set to your local system and a database named “NeoBatch”.

When it comes to viewing the reports, you have two different options available. You can either view the reports from the Report Viewer option, or view the reports from your browser. If you have not set up a report server, the report viewer is the default option. You can change the deployment location by going into the project properties and changing the TargerServerURL.

You may get a warning about no deployment server setup if you have not set one up. If you would like to continue just using the report viewer, that’s fine too.

Step 3: View the SQL Reports All right! The SQL reports should be running and displaying all sorts of information about your NeoBatch database.

The first page here is a summary of your NeoBatch system with a timeline chart first displaying the number of jobs you have performed in the last month.

Keep in mind that the default time window is 30 days in the past from tomorrow. So it will display jobs that you have executed the day you run the report. If you want to focus on a more specific time window, simply change the dates and times at the top of the window. These dates and times will carry through the entire report.

Scrolling down, you can see several other reports that display other metrics stored in your database, such as the average NeoBatch job duration, the jobs that took the longest to complete, and when the server was busiest. Let’s click on your job with the highest duration and see what it shows us!

Clicking on that job should take you to a different report, this one showing you different information about that particular job, such as how many minutes of CPU time the job used up, and the data input and output of the job.

You can also click on the Job ID or any of the jobs displayed in the graphics to drill down even further into the NeoBatch database, displaying data about a specific job id. Pretty neat, huh?

Do you have SQL report stories of your own?

If you have any cool SQL report stories you would like to share or if you have any suggestions for reports, please leave a comment below.