Y2K DATE FORMATS FOR PACKED FIELDS

Logical Expansion: Change date by adding a century indicator, but it
does not physically lengthen the field. For example, in PL/I, a lot of
dates are FIXED(6), YYMMDD, which uses 4 bytes of storage. Logical
expansion adds a century indicator to the field, creating a FIXED(7),
CYYMMDD, which still uses just the same 4 bytes. The usual values for
the century indicator are 0=19 and 1=20. This approach is used when
physical sequencing of records on a database is an issue.
 

Is there a way to describe this as a date to focus ? Something like
USAGE =YMD or P6YMD, ACTUAL=P4CYMD. IF NOT, CAN IBI ADD THIS
FUNCTIONALITY for packed field dates ?

Any good ideas/techniques on how to handle this short of having to
change the fields usage from P6YMD to P7 (which is no longer a date to
focus) and a whole bunch of defines ?

Any others out there in the same situation of having dates 'Logically
expanded' ?

Reply :

You should only need 1 DEFINE per date, I don't think you even need to
change the formats of your existing dates. They will carry on working as
P6YMD, except when you introduce the "1" for CC 20, then you'll see
"stars" on your reports.

The DEFINE should simply be :
NEWDATE/P8YYMD = OLDDATE + 19000000 ;

Would this be satisfactory.
 

What you have will work until you stick the 1 in front...then you'll
see a data overflow on your reports (*******). I'd suggest you handle
this sort of 'conversion' in your master. First, define the field as
usage p8, actual p4. Then create a defined field (in i8yymd format)
that adds 19,000,000 to the database amount. This can then be turned
into a smart date if you wish.
 

fieldname=filedate,,p8,p4,$
define cdate/i8yymd = 19000000 + filedate ,$
define sdate/yymd = cdate ,$
 

960212 1010212
19000000 19000000
------------- -------------
19960212 20010212

*
You can then do further
DEFINEs if you want to convert to FOCUS Smart dates. There is another
option, though. If the primary concern is not to use more data space to
store dates, but still allow compliance for Y2K, then I would suggest
using ACTUAL=DATE in your files. This relatively obscure format
allows you to use FOCUS 'Smart' dates in external files (VSAM, FIX,
IMS, etc.). It works exactly the same way as Smart dates in FOCUS
databases. The date is then stored in the file as an 4 byte integer
(2's complement) which is an offset (in days) from the FOCUS base date.
Your USAGE would then be any valid smart date usage (YYMD, YMD, YMDTr,
etc.). Of course, this means reloading the data via a FIXFORM MODIFY or
MAINTAIN. It also means that any external programs you use will need
to include support for a smart date format like this.

Reply :

"Old Dates", be they I, A, or P, are what got us in this Y2K mess in
the first place! Having the century in an "Old Date" makes them correct in
context, but for FOCUS systems, why not go the extra step and convert them
into a usable Smartdate? There are exceptions to this rule, but more
often than not, the benefits of this final Smartdate conversion will
pay off in the long run.

Reply :

Having 8-character "dumb" dates in flat-files (or whatever) works great for
sorting purposes, but try to add 30 days (or whatever) to one these "dumb"
8-character dates, and let me know what you get... March 45th??... February
37th ?? . THAT'S one of the 'non sorting' benefits of Smartdates!

As far as a different Basedate, I have not heard of this. I know that the
DAxxx and DTxxx (prior to 7.0.8) Subs are based on a "start" date of
12/31/1899, running through 12/31/1999 (100 years), so any "cross-conversions"
between Smartdates and these Subs MAY require you to add the missing year,
1900 (365 days).
 

Question :
" I have also been told but have not seen that on at least one release on one
platform Smartdate had a different base date."

I believe he was referring to FOCUS releases, in which case, my understanding
is that all FOCUS Smartdate Basedates, regardless of the platform or release,
are 12/31/1900. Is this true, or is there another Basedate out there on some
release?

On the other hand, if John was referring to different products, your statement
is correct in that it dosen't matter WHAT Basedate is used as long as the
software can interpret it correctly.
 

There was only one case where the base date was different between platforms,
and IMPORT is being fixed to handle that case. So, since the only way to
transport data from one platform to another is in character mode (where there
is no base date) or as a FOCUS database, where the IMPORT is required, my
original question is still valid.
 
 

The only problem I'm aware of, with base date, was that for YM type formats,
one platforms picked Jan, 1901 as the base date, rather than Dec. 1900.
Everything was fine, when run on THAT platform, but when you used IMPORT to
move to other platforms, the date was off by 1 month. IMPORT is being (has
been?) fixed to correctly calculate the offset, so this should not be a
problem.

WANT A LIST OF ISSUES FOR Y2K. IN REL 6.8 & MVS.

Also I would like to have a list of issues
that must be taken care of for making an application y2k compliant.
Like dates used in sort, comparisons, must be 8 char,
also what others?
 

Reply : ( By Chris Boylan of IBI )

ACTUAL=DATE works fine in FOCUS 6.8. But if you are working with
FOCUS databases, you don't need it. Any FOCUS smart date (in a
FOCUS database) automatically stores the date as an integer offset
from the FOCUS base date. If you are working with FOCUS databases
in 6.8, it would be a good idea to use full 4 character years in the
FORMAT of all date fields (FORMAT=YYMD, for example). This way
there is no mistaking the century. The DEFCENT and YRTHRESH
setting for default century and year thresholds are only available
in FOCUS 7.0 and above.

Your best bet if you are just getting started with FOCUS is to
contact Customer Support Services. (212)736-6130 or (800)736-6130.
You can check the web site (www.ibi.com) to see if they have
e-mail support - you will need your mainframe site code, of
course. You can ask questions on FOCUS-L of course, but this is
not an 'official' channel of support.

QUESTION :-
If in a Focexec a sort is on date_x, like " By date_x "
it's value is also displayed, is there any option by which I can
display the same 6 char date as it used to earlier, while now I sort
on a 8 character date. In short there is no change in the way a
report is displayed.

Reply :

FOCUS will always print a DEFINEd field first if it finds a DEFINEd
field and a real field of the same name. However, if you give the
DEFINEd field a different name (or rename the original field),
then you could always PRINT OLD_DATE_X BY ORIGINAL_DATE_X NOPRINT
to suppress the printing of the new date field, but still use it
as the sort field.
WHERE THE OLD_DATE_X IS THE 6 CHAR DATE, THAT IS PRINTED IN THE REPORT,
WHILE THE ORIGINAL_DATE_X IS THE 8 CHARACTER DATE.

Question: When to use the ACTUAL = DATE attrib?
Reply :-

You won't be able to use 'Actual=Date' because these are alpha fields. The
manual clearly explains that this can only be used when the actual storage
is a four-byte integer containing days offset from 12/13/1900.

However, you can immediately change the MFD's to A6MDY (or whatever)
without changing your programs. Even if the programs are full of computes
like YEAR/A2=EDIT(DATE,'$$$$99), the calculations will work whether the
original field definition is A6 or A6MDY. The advantage of A6MDY is that
you can define a smart date with one calculation, either in a COMPUTE, a
DEFINE, or in the MFD.

As to whether someone used A6 originally because of an old version or just
ignorance about Focus, it really doesn't matter. Date formats have been
around as long as I can remember (I don't have any old manuals and my
memory is going with my hair!), so my guess is that they used a simple A6
because these were external files.

It will be unfortunate if you can't upgrade to 7.08. If you can, then your
Y2K calculation will be like this:

NEWDATE/MDY = OLDDATE;

If you're stuck in 6.8, then you'll need to do windowing this:

ANEWDATE/A8MDYY = IF EDIT(OLDDATE,'$$$$99') LT 50 THEN
EDIT(OLDDATE,'9999') | '20' |
EDIT(OLDDATE,'$$$$99') ELSE
EDIT(OLDDATE,'9999') | '19' |
EDIT(OLDDATE,'$$$$99');
NEWDATE/MDY = ANEWDATE;

As to other things to look for, you're on the right track. A key question
is the volume of code you have. If you've got over 50,000 lines to scan,
you may want to consider a third-party tool which will handle dependent
field definitions.

Question : Sorting by a smart date.
We have a close date defined as follows (R7.something for MVS):

FIELDNAME =CLS_DATE ,E04 ,MDYY , $
I'm trying to set a flag on all records closed in a particular month using
a WHERE clause.

I tried CL_THIS_MO/I5 = IF CLS_DATE FROM 12011997 TO 12311997 THEN 1 ELSE 0;
and get nothing flagged, even though when I print CLS_DATE and CL_THIS_MO,
I can see records with a 12/97 close date.

CLS_DATE CL_THIS_MO
-------- ----------
09/26/1997 0
12/05/1997 0
02/12/1997 0
07/22/1997 0
06/13/1997 0

Reply :-
WHERE CLOSE_DATE IS-FROM '12/01/1997' TO '12/31/1997'

Smart dates should always be enclosed in single qoutes with slashes.
It works without quotes and slashes except when it doesn't work without
them...

Subject: Re: WHERE tests on Smartdates

I am just getting into Y2K stuff and have a question. This seems so
simple I am not sure if it will work.
We have a flat file with a literal date which we need to convert.
I have changed the Master file to read YYMD
In the modify to fixform the data in I am doing a compute

COMPUTE DATE/A8YYMD=;

Is this the correct way to convert this field for Y2K?
subject: Y2K - more questions

There are generally two kinds of dates that Focus works with.

The first is what I call a 'display date'. This is generally found
in older systems and is composed of a field that contains the
actual date. For instance this field might be 6 in length where by
the first two characters were the year, the next two characters
were the month, and the last two characters were used to store the
day as in 961231. If you were able to see the actual value of the
field in a file you would see the value 961231. This could be
stored in ANY storage format: alpha (A6, PIC X(06), CHAR(6), etc),
or numeric (P6, I6, D6). In Focus you used edit characteristics to
define such fields as dates to Focus so that Focus knows that the
value of the field is in date format and what order the components
are in. /A6YMD and /A8YYMD as well as /P8YYMD and /I6YMD could all
define an old date to Focus.

New dates (aka smartdates) have been around in Focus since release
5.5. These dates are stored as a number of days since the base
date. So internally if you could see the value of the field within
a file you'd might see a value of 32,002,102. This number is
converted to a date on output. This makes it very easy to add and
subtract from a date. These are defined to Focus simply with the
edit characteristics but no format or length. For instance /YYMD .
/YMD , and /MDY all describe the formating that is to take place on
output. This is similar to DB2's DATE formatted field.

So long as Focus understands that the fields are DATES you can
assign an old date formatted field to a new smartdate and
visa versa.

Now your flat file most likely has an old date which should be
described as A8YYMD (or whatever). You can read this into and
assign this to a field in a Focus file that is defined as either
A8YYMD of one that is defined simply as YYMD. With the A8 you have
an old date and without the A8 you have a new date. One is stored
as the number of days since the base date and one is stored in
year/month/day format.

Re: Y2K - more questions

A couple of questions ?
The external file -- can you actually view the date -- if so, it's
probably an Alpha string.
What sequence is the date in --- YMD, DMY, MDY?
Is the date in 6 digits or 8 digits.?
What do you mean by conversion ?
For Example.
If I had --- 981231 in my file, I could describe it as:
ACTUAL=A6,USAGE=YMD or using the DEFCENT/YRTHRESH
settings, I could also describe it as:
ACTUAl=A6,USAGE=YYMD, and a century component will be displayed.
If the value is 19981231, so the century is explicitly referenced,
then I could describe it as:

ACTUAL=A8,USAGE=YYMD.

AGAIN, if this is in fact an ALPHA field then in my MODIFY request
all I would have to do is to simply declare the length of the field
in my FIXFORM statement:
MODIFY FILE XXXX
FIXFORM extdate/6 or extdate/8.
Some of what I have illustrated will change, based on the internal
format of the incoming 'date' field.

Replacement for &MDY

I use &DATEYYMD to display the current date on a report, it includes "/":
1998/02/25.
Question :

Some of the more 'popular' &DATEfmt formats are listed below, suitable
for execution within your release of Focus.

-TYPE &3DATEYMD = &DATEYMD
-TYPE &3DATEYYMD = &DATEYYMD
-TYPE &3DATEYYBMBD = &DATEYYBMBD
-TYPE &3DATEDMY = &DATEDMY
-TYPE &3DATEYY = &DATEYY
-TYPE &3DATEM = &DATEM
-TYPE &3DATED = &DATED

I use &DATEYYMD to display the current date on a
report, it includes "/":
1998/02/25.

Is there a way to get this without the "/" using the "&" command.
I believe one of the variations of &DATEfmt (ie &DATEYYMD) will work
in that release .

The only thing I can suggest is:

-SET &DTYYMD = &DATEYY | &DATEM | &DATED;
-TYPE &DTYYMD

Reply from IBI :-

As of Release 7.0.7(IBM Mainframe) the &DATE variable was enhanced
so that one could use many popular DATE/EDIT options e.g.
&DATEYYMD, &DATEDMYY, &DATEMDYY, etc
It thus return an ALPHA string with the forward slashes, so if you
do not want the slashes you have to EDIT them out.
Currently there is no &YYMD variable.
B.J.
        Continue further there are more questions in the   Next page  and subsequent pages !