Christmas 2001
In this issue....
As it's Christmas and all through the house there are messages of "Buy buy buy" oozing from every TV and newspaper, we're going to do something different. In this issue, we're going to include nothing but handy hints about some of our more popular products as well as a couple you may never have heard of. We all hope they come in handy some day.
Here's a couple of ways that EasyLogic can save you a heap of time on data entry and verification of data. The first example is an account application form that includes a main account holder's name and up to 6 other family members. The fields are called FIRST1, SUR1 up to FIRST7, SUR7. The next field is called DATE. Most of the batches of data contain records with no more than 4 people on the form and in 99% of cases they all have the same surname. The following piece of EasyLogic (which works in PC Key/Master, not the mainframe flavour, but read on) will skip over unneeded fields as soon as a first name field is skipped. It will also put SUR1 into any surname field that is skipped but for which a first name was entered.
AFTER FIRST2 EDITS IF FIRST2 NOT ENTERED THEN SKIP TO DATE ENDIF AFTER SUR2 EDITS IF FIRST2 ENTERED AND SUR2 NOT ENTERED PUT SUR1 IN SUR2 ENDIF AFTER FIRST3 EDITS IF FIRST3 NOT ENTERED THEN SKIP TO DAT ENDIF AFTER SUR3 EDITS IF FIRST3 ENTERED AND SUR3 NOT ENTERED PUT SUR1 IN SUR3 ENDIF AFTER FIRST4 EDITS....
And so on.
Tip 2 - This one is going to save you a lot of time during verification and works on both the mainframe and PC flavours. Same example as before but this time we don't want to verify any of the fields that haven't been entered in the batch. So we use the SET VERIFIED / SET NOT VERIFIED function of EasyLogic to say that we don't or do want to verify a field. This function takes effect for every record in a batch so if your EasyLogic says "SET VERIFIED SUR7", SUR7 will be regarded as verified in every record in the batch, not just the record whose EasyLogic issued the command. So what we're going to do is to set all the FIRST & SUR fields to VERIFIED at the start of the batch and set them to NOT VERIFIED only if some data is put in them.
So, on the batch header, we say :-
SET VERIFIED DETAIL:FIRST2 (where DETAIL is the name of the detail format) SET VERIFIED DETAIL:SUR2 and so on for FIRST3-7 & SUR3-7.
For the detail record, we say :-
IF FIRST2 ENTERED THEN SET NOT VERIFIED FIRST2 ENDIF and so on for all the other fields.
Tip 3 - Another cunning use of SET VERIFIED (PC and mainframe) is on a batch where you are totalling an amount field for comparison against a total in a trailer record. You can use it to say that, if the totals match then you don't want to verify the amount fields. So the Easylogic for the DETAIL record says :-
ADD AMOUNT TO ACCUM-1
And the EasyLogic for the TRAILER record says :-
IF ACCUM-1 TOTAL THEN SET VERIFIED TOTAL SET VERIFIED DETAIL:AMOUNT ENDIF
And, just to keep you on the edge of your seats, next month we'll have news of some even swisher new verify features in EasyLogic. They were developed in response to a customer suggestion we got last month - That's what we call customer service, Microsoft!
... you can believe what your network monitor tells you. A customer complained that the numbers in Vital Signs were dud. The numbers were implying that the IP interface was running 100%, 24 hours a day and 7 days a week.
When we isolated the terminal running such high throughput, we found an error in the backup program. Instead of running once or twice a day to back up the PC, it was looping and running one backup after the other with no waiting. Clearing up this application error allowed the MIS department to service more customers with the same resources.
Using the daily and weekly reports on CSM usage from VSV will help you tune your systems for different workloads for different times of day and different days of the week and month. Sometimes the larger buffers are more in demand and sometimes smaller buffers can get the work done more efficiently. By knowing when to adjust buffer sizes lets you service customers so they do not see bottlenecks in getting many small FTP's through or in getting the larger FTP's through when doing large back-ups. Santa's reindeer must be flexible to deliver the goods in a timely way!
Using PF1 HELP to identify the meaning of "Result Codes" from completed FTP's can give you insight about growing problems before they o
ccur. These same codes can be found in RFC1213, but who takes the time to look them up? One MIS customer called his client to ask why they were asking for a record which was protected. Research found an error in an application which was producing incorrect bills for customers. This clue was the input needed to solve this nasty customer relations problem.
There are rumors in Minnesota, USA, (see picture==>>) that snow may be late this year! Then Santa will have to use one of the Ford trucks made in Minnesota. This should help the unemployment, but only slightly. The Reindeer are very nervous about losing their jobs! This has never been a problem before and they do not have this situation covered in their contracts with Santa.
Some tables in the Aperture database can get very large and many of the entries may no longer be needed. An obvious example is the Manufacturers' Device Specs table (which I will mercilessly abbreviate to MDS) that we supply as part of TechDoc. It has well over 20,000 entries, some of which are for manufacturers and devices you don't have, never have had and never will have. You can use Aperture's table editor to delete the unwanted entries but there is a quicker way.
What you do is this :-
If you want to make the WHERE expression a bit simpler, you can use the DECODE function to give a value of "Y" for those manufacturers you want and "N" for those you don't want. As in
'MDS'.'Manufacturer' Decode("SUN":"Y","IBM":"Y","HITACHI":"Y","N" ) = "Y" to dump everything but IBM, Sun & Hitachi.
Another option is to turn the Decode back to front to dump the ones you don't want. So, to get rid of Trane and Piller you can use 'MDS'.'Manufacturer' Decode("TRANE":"N","PILLER":"N","Y" ) = "Y"
Or you could create a table called "Wanted" that contains 2 fields - manufacturers' names and a field called 'Keep' containing a "Y" if you want to keep that manufacturer. Then the expression becomes Lookup('Wanted'.'Keep','MDS'.'Manufacturer' ) = "Y" and you can use it to keep as many or as few manufacturers as you like.
Seems like everyone wants to web enable their mainframe applications with z\Web-Host but, for some odd reason, they don't trust the www. So Cyrus has put together some tips for anyone who has using z\Web-Host in mind.
The main question is what you intend to support. Internal Displays, used only by your own people, are the easiest. In this case, the major security is provided by the excellent facilities of OS/390 (or VSE) itself. People dialling in (just as with TN3270) are restricted by the usual firewall provisions. If you like, an extra level of security can be provided at connection time with its own passwords. Once in, the potential user must go through normal TSO or CICS logon with its own password procedures. As an additional layer, once a connection is established, z/Web-Host maintains an internal transaction id for security purposes to insure that sessions are not pirated or picked up by unauthorized users following an abnormal disconnection.
External Displays, used to provide displays to the World Wide Web are generally more of a challenge. Here the major burden is on the design of your CICS system. As set up by default, CICS allows entry of any transaction from a blank screen. This allows all sorts of inappropriate accesses, and the solution is to control all transaction entries with RACF to ensure that holders of default security (typically code 0) are ONLY allowed to execute transactions that are OK. z/Web-Host can then be set up to allow signon from an external browser to log on as a default ID. Typically no TSO access is provided through such a signon. A back-door using a non-published HTTP port may be set up to provided more general access to authorized system users with its own signon procedure. If you are feeling particularly cautious, a separate CICS instance can be run which contains ONLY the set of permitted CICS transactions and for which read-only access is provided.
Once a connection to the restricted set of CICS transactions is permitted, it is probably a good idea to set up specific webscreens for the permitted set. These can be coded in such a way as to hide all regions of the screen that do not display appropriate data, either because of confidentiality or because they contain internal codes that may not be meaningful to the casual observer. The screens can also be dressed up with low-level HTML to provide a more meaningful display to the external browser user.
This is a bit more work, but is necessary for any system that intends to provide direct mainframe access to the general World Wide Web. Perhaps we mainframers are overly cautious, but a good deal of inappropriate activity goes on out on the Internet and any exposure to this unfriendly environment requires appropriate caution. z/Web-Host allows a great deal of external access potentially, and it is essential to make sure it is not abused.
No, we're not getting into internet marketing but here's a few web sites and products that I like.
The best jam in New Zealand (easily the equal of that $10 a jar stuff from England) - www.anathoth.co.nz. Don't let the odd name or the plastic pots put you off! If you can't get it in Australia - tough.
A decent drop of beer - www.monteiths.co.nz
We usually put a bit at the end of our snail-mail newsletters saying "Save a tree" and suggesting you may like to get your copy by email instead. However, in keeping with a grand old tradition, I'm now off to grab an innocent pinetree to shove in my living room for the next few weeks.
In response to our last newsletter, we've expanded the list of money-making opportunities on our website on a page called whatabloodyripoff.htm. If you believe in the tooth fairy and that all politicians and real-estate agents are honest, you'd probably do well not to visit that page...
To the generous people who let us use their Christmas graphics here. You can find them all at http://webclipart.about.com/library/Xmas/blxmas48.htm
I intend to make a major annoyance into a pleasure. I'm going to put a dollar into the pot on
my desk every time Windows crashes and take my lovely wife out to dinner every month
on the proceeds. I suspect we will be going to Hammerheads more often than we go to McDonalds - I started at 8 a.m. this morning and there's 3 bucks in there already. Make that 4. No, 5.
By Robert, aged 60 and 5/12
The north wind doth blow,
And we shall have snow,
And what will poor Robert do then?
He'll sit in his Dodge,
And drive through the slodge,
And hope that he gets home again.
have a marvellous Christmas and a great New Year. And, if you do anything I wouldn't do, please email me the photos.