Problem with Y "smartdate" format
                                        MFD CHANGES FOR Y2K
                                       Comparing 2 smartdates with different formats
                                       Why aren't smart dates part of Dialog Manager?
                                       Y2K compliance of User written Routines.
                                       Validating Y2K Dates
                                       Explicit Indexing & JOIN.

Problem with Y smartdate format

New finding...
Our testing in 7.0.8 seems to show that the "Y" format does not respects
the DEFCENT and YRTHRESH setting. Anyone else seen or can confirm this?
The Problem...

I have been experimenting with the yy format in focus 7.05 mvs release.
I like using this in place of an i4 field for a date, as you dont have
to put in all kinds of edits if you put a value in that is not a year.
What is the default for yy? It seems to be 0. Since the base date
is 12/31/1900 I thought the default might be 1900.
------------------------------

Reply

The base year for /YY (at least as of 7.0.6) is 0000, not 1900. And
that's smart: If the base year were 1900 (meaning "1900" would be
stored as +0), Focus would have to print blanks for year 1900, or print
1900 when the variable is 'empty'.

On the other hand, format "Y" is decidedly unsmart:
Moving an explicit date to a /Y discards the century digits, storing a
2-digit value, so that 1900 or 2000 becomes indistinguishable from null;
and moving a /Y to a /YY adds century digits back, based on
defcent/yrthresh settings, as in moving a /I6mdy to a /YY.

Try this:
SET DEFCENT=19,YRTHRESH=00
DEFINE FILE CAR
I1/I4YY WITH COUNTRY =1950; YY1/YY=I1; Y1/Y =I1;
I2/I4=Y1; YY2/YY=Y1;
END
TABLE FILE CAR
PRINT I1 YY1 Y1 I2 YY2
IF COUNTRY EQ FRANCE
END

In 7.0.6, I get:

I1 YY1 Y1 I2 YY2
-- --- -- -- ---
1950 1950 50 1950 3850 (!)

In evaluating "YY2/YY=Y1;", Focus (expecting Y1 to contain a value from
00 to 99) added 1900 (=100*defcent) years to the internal content of Y1,
not noticing that Y1's content was outside the expected range.

Reply from IBI.

Y and YY format dates are not FOCUS 'SMART' dates --- they are
simply Integer values, and do NOT represent any offset for a base
date.
 

Reply

I am inclined to agree with Jack.
I think Jack's first example ably proved via I2 (with format I4) that /Y
is definitely not storing 2 digits. Rather I2's value of 1950 firmly
supported Jack assertion that /Y is a Smart Date and stores the offset
from base year 0 B.C.

The erroneous value of 3850 for YY2 looks to me as a bug (perhaps
introduced by Project 2000's DEFCENT and YRTHRESH enhancements).

I am not clear whether DATE_I8YYMD's erroneous value of 0098/01/29 is
as expected under Project 2000's DEFCENT and YRTHRESH specifications or
is a Project 2000 bug.

I disagree. /YY is a perfectly smart date format -- albeit with a
different (and smarter) base-date year than IBI chose for the day-level
smart dates]. Consider:

DEFINE FILE CAR
DATE_I6YMD /I6YMD WITH COUNTRY = &YMD ;
DATE_I8YYMD/I8YYMD WITH COUNTRY = DATE_I6YMD;
DATE_YYMD /YYMD WITH COUNTRY = DATE_I6YMD;
DATE_YY /YY WITH COUNTRY = DATE_I6YMD;
END
TABLE FILE CAR
PRINT DATE_I6YMD DATE_I8YYMD DATE_YYMD DATE_YY
IF COUNTRY EQ FRANCE
END
NUMBER OF RECORDS IN TABLE= 1 LINES= 1

DATE_I6YMD DATE_I8YYMD DATE_YYMD DATE_YY
---------- ----------- --------- -------
98/01/29 0098/01/29 1998/01/29 1998

The /I8YYMD format is dumb: Focus makes no adjustment, to discard or
supply date components, when stuffing a date into it;
whereas /YY is smart: Focus supplies the missing century digits ('19')
when moving a /I6YMD (containing +980129) into a DATE_YY/YY.

Reply from IBI.

The Y and YY formats are very misunderstood. They ARE NOT SMARTDATES.
Meaning they don't store an offset from a base date. They are integer
fields at 2 and 4 bytes respectively. They will store the actual
number which is your 2 or 4 digit year. Therefore, DEFCENT and YRTHRESH
have no effect on them standalone. If you convert from a YY to say a YYMD
adding month and day then you have a smartdate. Internally this new
field will also be an integer date but it will have the number of days
since 12/31/1900. This is an integer which represents an offset not the
actual year. The manual doesn't do such a good job at pointing this out.
So we do shoulder some of the burden in not spelling this out clearly.
But please understand that Y and YY are not smartdate formats.
They are old date formats.

Thank you,
Peter Kruskopfs
FOCUS Product Manager
Question.
Subject: passing parameters

I seem to remember this being discussed on this forum some time ago but I
couldn't find it anywhere. Is there a way to pass a parameter from one focexec
to another?

I'd like to create a global focexec that my users can use that will set
DEFCENT/YRTHRESH to 1 of 5 options:
- system setting if no parm is passed
- any of 4 date ranges based on what the parm value is (1,2,3,4)
We do this in the COBOL world and I'd like to provide it on the FOCUS side
too.

I thought of doing:
-INCLUDE DATEWIND
but I don't think you can pass parameters in an INCLUDE statement. The simpler
the method, the better.
Any ideas?

Reply.

If you -INCLUDE DATEWIND in every FOCEXEC that you need to set
DEFCENT/YRTHRESH in, then those parameters will be available in that
FOCEXEC...

Reply from Randy Gleason

I guess it depends. There's all sorts of ways
depending upon what you're attempting to do. Here are
just a few off the top of my head:

1) EX Fname parm1,parm2,parm3

This form will set dialog manager variable &1, &2, and &3
to the values you pass. (see -DEFAULTS command, too).

2) EX Fname var1=parm1,var2=parm2,var3=parm3

This form will set dialog manager variable &var1,
&var2, and &var3 to the values you pass. This is
similar to #1 above except you actually name the
variables to be set rather than using the &1,
default variable names.

3) Use GLOBAL amper variables (&&) rather than local
amper variables (&). GLOBAL amper variables persist
within the Focus session across focexecs. They do not
persist across multiple Focus sessions.

4) Write to a file then -READ the value back in. This works
well for passing values between 2/3gl and Focus and between
Focus sessions.

So I guess you could execute a focexec (EX DATEWIND 1 for instance)
rather than -INCLUDING it and get your results.
 

MFD CHANGES FOR Y2K

I am working on the Y2K Conversion for TI. I have come across an MFD which
uses the system date in a date function to calculate the difference between
todays date and another date.

FIELDNAME = LAST_CONT,ALIAS= ,USAGE=A8 ,ACTUAL=A8 ,$
DEFINE ALAST/A6 = EDIT(LAST_CONT,'99$99$99');$
DEFINE ILAST/I6YMD = EDIT(ALAST);$
DEFINE DAYS/I6 = YMD(ILAST,&YMD) ;$
FIELDNAME = WIN_DATE ,ALIAS= ,USAGE=A8 ,ACTUAL=A8 ,$
FIELDNAME = STATUS ,ALIAS= ,USAGE=A1 ,ACTUAL=A1 ,$
FIELDNAME = REASON ,ALIAS= ,USAGE=A1 ,ACTUAL=A1 ,$
DEFINE STAT_RSN/A3 = STATUS!'/'!REASON; ,$
DEFINE DEL/A1 = IF STAT_RSN EQ 'A/P' THEN ' ' ELSE
IF DAYS GT 120 THEN '*' ELSE ' ';

This is using MVS FOCUS 6.0. When I try and use the &DATEYYMD variable
under FOCUS 7.06 I receive the following error message.

FOCUS 7.0.6 09.03.31 03/04/98 RPENDING LINE 7 8188.01

TABLE FILE TITANWOR
(FOC104) DEFINE IN MASTER REFERS TO A FIELD OUTSIDE ITS SCOPE: DAYS
ERROR AT OR NEAR LINE 7 IN PROCEDURE RPENDINGFOCEXEC
(FOC258) FIELDNAME OR COMPUTATIONAL ELEMENT NOT RECOGNIZED: &DATEYYMD
(FOC101) ERROR IN DEFINE IN MASTER FILE: TITANWOR....
 

Does anyone have any suggestions as how to make this master Y2K compliant???

Reply From: Jay Converse

If I'm not mistaken, DEFCENT and YRTHRESH work with MFD's just fine, so you
don't need the CC component. This should work:

FIELDNAME = LAST_CONT,ALIAS= ,USAGE=A8 ,ACTUAL=A8,$
DEFINE ALAST/A6YMD = EDIT(LAST_CONT,'99$99$99');$
DEFINE ILAST/YMD = ALAST;$ <-- DEFCENT kicks in here
DEFINE ITODAY/YMD = &YMD;$ <-- and here
DEFINE DAYS/I6 = ITODAY - ILAST;$

And as long as this MFD is never used for Compiled MODIFYs, the &YMD will
be OK.

Reply From Art Greenhaus.
One suggestion...
In the DEFINE for ITODAY, change it to:

DEFINE ITODAY/YMD DFC 19 YRT 90 WITH LAST_CONT = &YMD;$

We don't recommend putting D.M. variables in a MFD DEFINE (what would happen if
you COMPILE a procedure?). If you don't mind adding another line, here's a way
to so it that should work for the next 90+ years:

DEFINE ATODAY/A6MDY WITH field = EDIT(TODAY('A8'), '99$99$99');$
DEFINE TODAY/MDY DFC 19 YRT 95 = ATODAY;$

The first DEFINE uses the TODAY UWS, which only returns a 2 digit year. The
second DEFINE says that the 2 digit year is between 1995 and 2094.

Question :
Subject: Tomorrow's Date
Is there no simple way to set tomorrow's date in a variable?
Do I have to use a user written subroutine?

This, of course, does not work:
-SET &TOMORROW = &DATEYYMD + 1;

TABLE FILE SL1000F
PRINT EFFECTIVE_DT
REG_PRICE
BY SKU
BY STORE_NBR
WHERE EFFECTIVE_DT LE &TOMORROW
END

Neither does this:

WHERE EFFECTIVE_DT LE &DATEYYMD + 1

In FOCUS for IBM Mainframe, version 7.0.7M

Reply From: Art Greenhaus

How about:

-SET &TOMORROW = AYMD(&YMD,+1,'I6');

Subject: Re: Tomorrow's Date
If all you need is a WHERE clause, just rearrange
WHERE EFFECTIVE_DT LE &DATEYYMD + 1
as follows:
WHERE (EFFECTIVE_DT - '&DATEYYMD') LE 1;

When the date is quoted, and the date-string is combined directly with a
declared date variable (using an arithmetic or logical operator), the
parser recognizes it as a date value and converts it to a date-offset
integer.

Reply From: Chris Boylan

Does it have to be a variable? How about a DEFINE? TEST2 below is a
smart date with tomorrow's date. You could always write this out to
a file and -READ it back in as an &VAR.

DEFINE FILE CAR
TEST/YYMD WITH CAR='&DATEYYMD';
TEST2/YYMD=TEST+1;
END
TABLE FILE CAR PRINT CAR TEST TEST2
END

Regards,

Chris

Will this work with Year 2000 compatible dates in release 7.0.8?

In fact, check out what the TODAY() function in FOCUS Six returns for years
greater than 1999.

Interestingly, YES. The values for literals in date format use the values
from DEFCENT and YRTHRESH to determine the century. Here's how I tried it:

DEFINE FILE CAR
XDATE/I8YYMD=DECODE COUNTRY(ENGLAND 19980101 FRANCE 19990101
ITALY 20000101 JAPAN 20010101 ELSE 20020101);
DATE/YYMD DFC 19 YRT 80=XDATE;
END
TABLE FILE CAR
PRINT DATE BY COU IF DATE FROM 000101
END

Reply From: David M. Briars
Subject: Re: Tomorrow's Date

It's also crude and unacceptable to have to write a date out to a
file and have to re-read it to get the data you need. If you don't
need a Define/Table to generate the correct date, why should you be
forced to do so??
I can see your point of view. I have a little different point of
view. One of the strengths of FOCUS is the way the different
components (TABLE, MODIFY, Dialogue Manager,..) work together.
Like most FOCUS professionals, I began to use Dialogue Manager
(amper variables) to support TABLE. When I was taught that TABLE
can support Dialogue Manager, (see earlier messages in this thread
for an example) I was quite impressed. I have used DEFINE/TABLEs
ability to handle complex computations (date,..) and then pass the
results on to other parts of the focexec/system via Dialogue
Manager (-READ..), for some time now, with good results.

Other members of the FOCUS community have asked IB to add smart
dates to Dialogue Manager. National FUSE has a list of 'System
Enhancement Requests' (TCC Enhancement Ballot). On my copy, from
the Orlando 1994 Conference, I see that this is requested and that
IB's response is marked as 'planned'.

I believe members of the FOCUS community have asked IB to enhance
Dialogue Manger (make it more robust). Other than the TCC list I'm
not sure to what extent this request has been documented.

Comparing 2 smartdates with different formats.

We are running 7.0.5 under TSO.

I had an instance where I was doing a field-to-field comparison of 2 date
fields that had different formats, for example DATE1/MDY and DATE2/YYMD.
When I did a TABLE on the file with a WHERE DATE1 EQ DATE2, FOCUS could not
figure out when they were the same date! If one was 03/03/98 and the other
was 1998/03/03, FOCUS thought they were different. I find this surprising
if they are supposed to both be smartdates, no?
Does anyone know if this has been fixed in a later release?
Peter

Reply From: Randy Gleason
Admittedly contrived but this seems to work as I'd expect
in all the releases that I have access to. As such I guess
we'd need to see code and results.

DEFINE FILE CAR
MYDATE/YYMD WITH COUNTRY ='1998/01/01';
YOURDATE/MDY=IF COUNTRY EQ 'ENGLAND' THEN '01/01/98' ELSE '03/01/98';
END

TABLE FILE CAR
PRINT COUNTRY CAR MYDATE YOURDATE
WHERE MYDATE EQ YOURDATE
END

 Why aren't smart dates part of Dialog Manager

Smart dates aren't part of Dialogue Manager becuase there are no FORMATS in
Dialogue Manager. How you you indicate a variable contained a 'smart date'?
The Dialogue Manager just stores and manipulates character strings.

Y2K compliance of User written Routines

Reply from Art.
'Y2K compliant', has several levels of meaning. As written,
all the UWS will accept 4 digit years and product the correct result (with a
4 digit year, except the DAxxx and DTxxx routines, which have been re-written.
So, if you provide 4 digit years, they're already compliant.

A second level of 'compliance' is the ability to use DEFCENT and YRTHRESH,
when converting from a 2 digit year to a 4 digit year. These are FOCUS setting,
and, as such, the UWS had no access to them. We have modified them to recognize
DEFCENT and YRTHRESH, and re-written the DA and DT routines to support 4 digit
years. This support is available with the 7.0.8 release, with a PTF needed to
provide D.M. support.

In addition, we've modified the routines, such that, if you specify the format
of the return value, you can control how many 'year' digits are returned, while
the subroutines will use 4 digit year processing internally.

Validating Y2K Dates

We are working with FOCUS MVS 7.06 and are trying to determine the most accurate way to validate a data entered
date that has the century within the date (i.e. 03051998). I
heard that the User Written Subroutines are not compliant
until v7.08. Is this true?

Reply .

If you're talking about a date entered on a CRTFORM, just make the field a
smart date... format validation for the field is automatic. I have added a
HELP clause in the MASTER for the field so that a meaningful message is
displayed:

FILE = SA1000F, SUFFIX=FOC,$
SEGMENT = SAMPLE, SEGTYPE=S1,$
FIELD = TAG_NU , ALIAS=TAG , FORMAT=A06 , FIELDTYPE=I,
TITLE='CONTROL,NUMBER',$
FIELD = RECEIV_DT , ALIAS=RDT , FORMAT=YYMD ,
TITLE='DATE,RECEIVED' ,
HELP='The format for this Date field is YYYYMMDD',$
Question.
Subject: Re: Compare Two Data Bases
I am using Focus Six for Windows and would like to compare two data bases
and generate a report that list all the differences between the two. The
two data bases are the same structure; one contains current month data and
the other prior month data.
Reply .

What structure do the DBs have? For single segment files of 'reasonable' size,
you might want to use MATCH FILE. If the files are very large, you might want
to use JOIN (from a to b and b to a), merge the output differences.

EXPLICT INDEXING & JOIN.

We are using FOCUS 7.06 on MVS/TSO -
1) When using explicit indexing,
( TABLE FILE XXXX.INDEXFIELD ) is it necessary to
also include the index fieldname on the define statement if
used
( i.e. DEFINE FILE XXXX.INDEXFIELD )?

2) When resolving pointers for KU or KM join
structures,
what should the DISPOSITION of the Host and Joined
tables be to enable the join pointers to be resolved when
new data is added to the tables using TABLE or TABLEF?
All of our FOCUS databases reside on SINK machines
when data is added to Static joined tables and the pointer
resolution is attempted.

Reply Re: EXPLICT INDEXING & JOIN.

1. ALL DEFINEs without an alernate file view are STILL valid with an alternate
view.Only when the DEFINE REQUIRES the alternate view (i.e. referencing
fields in two paths) is the alternate view DEFINE needed.

2. Pointer are ONLY resolved with DISP=OLD, and NEVER on a SINK machine. Take
the sink offline, and resolve the pointers locally. since the pointers
are only resolved in the host file, that's all that needs DISP=OLD.
Continuation of Indexing.
1) Would the processing be inefficient to always include a
DEFINE view when a TABLE view is setup? If the
DEFINE view was needed but not specified what type of
errors or results would occur.
2) Does a REBUILD,REBUILD resolve pointers in the
host file when Static joins are used?

Reply :
1. ALL DEFINEs without an alernate file view are STILL
valid with an alternate view.Only when the DEFINE REQUIRES the alternate
view (i.e. referencing fields in two paths) is the alternate view DEFINE needed.
2. Pointer are ONLY resolved with DISP=OLD, and NEVER on a SINK machine.
Take the sink offline, and resolve the pointers locally. since the
pointers are only resolved in the host file, that's all that needs
DISP=OLD.
Reply For Q1:
1) If you DEFINE a field with an alternate view, it's only available FROM that
alternate view. And, if you don't reference a DEFINE, it's overhead is
infinitesimal.
Reply For Q2 :
2) No, REBUILD just dumps and reloads data. Pointers must then be resolved
separately.
    Continue reading there are more questions in the   Next page  and subsequent pages !