EMR / Smartdates using FOR

P.S.> We're running 7.05 under OS390, but achieved the sames results
when running under our test environment for 7.08...
Reply From BJ :
Subject: Re: EMR / Smartdates using FOR
Michelle,
Please ipen up a case with Customer Support. A small working
repro would be greatly appreciated.
When you open up the case, have it transferrred to me.
thanks, B.J.

Reply From: Noreen Marie Redden
Subject: Re: EMR / Smartdates using FOR

Michele: As BJ has said, we have reproduced your problem. It's not
an upward compatability problem, as the same problem occurs in early releases
of FOCUS, but it sure is a puzzlement. Of course, your workaround is to go
back (via a DEFINE if necessary) to a "traditional date", but it is definitely
a bug.

MFD field Limitaion.

FOCUS 6.13 out of the box supports Masters with up to 3072 fields
and a maximum combined field length of 26624 bytes (results of the
"? CONFIG" command), BUT there is a problem using a Master even
remotely that large in Report Painter or Report Assist.

Take a look at www.uncc.edu/ais/eda/edaerr.htm, item number 3. The
author claims that there is a limit of approx 32K (and/or 600 lines)
for Master files when entering Report Assist or Report Painter. (ref
IBI Case number 2064-1037). I can say from personal experience that
there is some limit, but this page has facts.

FOCUS / IDMS INTERFACE.

1) What I want to know is what are the DUPLICATE= and COUNT= ?
There is a '$' that makes them to be ignored sure- but just for
knowing's sake ....

FIELD=CJPCD_RCD_CH_CENT ,ALIAS=F3503_41S ,A2 ,A2
FIELD=CJPCD_RCD_CH_CENT ,ALIAS=F3503_41T ,A2 ,A2
$DUPLICATE=CJPCD_RCD_CH_CENT ,COUNT=21,SEGNAME=S3503_01
this is just a 'segment' of the actual seg for which the alias is from
F3503_41A to F3503_41T.
It appears that this MFD was created using AutoIDMS. The $DUPLICATE
entry and its contents are generated by AutoIDMS for information only.
It is not used in any way. The ALIAS has the format created by
AutoIDMS:
'F' - record number - '_' - sequence number - optional suffix

The optional suffix is only appended to the alias when the same IDMS
record is selected to be described multiple times. This can occur
easily with the IDMS network structure, particularly with
bill-of-materials. AutoIDMS adds an alphanumeric suffix to the ALIAS
when the record is used more than once (blank for the first occurence,
'A' for the second occurence, and so on). But if the record were
described multiple times, you would see all fields in the record
duplicated, each in separate segments. They wouldn't appear in the
same segment with different suffixes.

AutoIDMS will also create multiple FIELD= entries when an IDMS field
is larger than 256 characters. But there will only be enough fields
added to the MFD to account for the total length of the long field.
Each will have a length of 256 characters. And the new fieldname will
either be blank or 'AUTOPADnnn', depending on the release. A suffix
is NOT added to the ALIAS.

You might want to recreate the MFD using AutoIDMS again to eliminate the
possibility that some of these changes were made manually. If the
problem persists, open up a call with Customer Support and we will look
into it further. Have the MFD, AFD, and subschema description
available when you call.

Also two more things.
2 ) Since Focus has a Hierarichial structure and IDMS a network structure,
how is a IDMS DB described to FOCUS, esp as there can be many records
in IDMS DB that do not have any parent and also some the are
free floating (which is neither a parent or a child). How are these
described.
When describing IDMS network structures to FOCUS, you have to create a
heirarchical structure. AutoIDMS really helps you do this. IDMS SET
relationships are used to identify heirarchical relationships. For
example, an owner/member set is analogous to a parent/child structure.

Records that don't have 'parents' (i.e., owners) are only described as
'children' (members) or as single segment files. 'Free floating'
records are described as single segment files.

> 3) What is the SEGTYPE=S option?.
> I know of SEGTYPE=,, and SEGTYPE=S0.

SEGTYPE=S indicates a multiply occuring segment in IDMS. The other
option that you can use with IDMS is SEGTYPE=U. This identifies a
child segment that occurs only once. It is only used when describing
the member of a set as the parent in FOCUS. AutoIDMS determines the
appropriate segment type for you.

FOCUS will assume SEGTYPE=S when you use either SEGTYPE=blank or
SEGTYPE=S0 for IDMS files. For FOCUS databases, SEGTYPE=blank means
that there are no keys and the data is stored in any order. SEGTYPE=S0
also means that there are no keys, and data is stored in the order that
it is input.

Rob Freeman - author of AutoIDMS

TODAYY ROUTINE

Reply:
I agree it would be easier if we produced a TODAYY routine (which we have every
intention of doing). BUT, by using DFC and YRT in your MODIFIES, they'll
continue to function correctly for the next 99 years. Whether you ADD the DFC
and YRT parms, or change TODAY to TODAYY, you STILL have to change the
procedures. Since DFC and YRT are available NOW, you can use it NOW, or wait
until we get to a TODAYY routine.

More Replies Regarding TODAYY From IBI :-

I agree as to the importance of a TODAYY routine. But, look at it from IBI's
point of view. Since DFC and YRT, used with the current TODAY, solve the
problem for the next 99 years, we felt we had time, and should solve problems
WITHOUT solutions. If one of those problems were yours, which would you want us
to devote manpower on?

We WILL produce a TODAYY routine, and I'll try and get it into the next release
if possible.
Art Greenhaus.

Question:-
Subject: Converting a date format from an external file...

Has anyone ever had the opportunity of converting a date format such
as 2-apr-96 into a smart date format, which can be reused within our
focus applications?

There do not seem to be any subroutines, which can achieve this.

Subject: Re: Converting a date format from an external file...

I have files with this kind of format and the only way I can convert
them to smart dates is through defines. Parse the elements, perform a
decode on the month (apr 4, may 5, etc.), and then concatenate the
elements back into mdy or ymd and finally define a smart date.

Maybe somebody else has an easier way.
Reply :
Subject: Re: Converting a date format from an external file...

Oddly enough,

DEFINE FILE xxxxx
SMARTY_PANTS/YYMD = '2 APR 96';
END

From: Michael Lazarski
Subject: Re: Converting a date format from an external file...

'2 APR 96 works because Focus can tell which part is the day and which
part is the year. This does not work with '2 apr 02' (simulating 2002).
Focus gives the error "invalid date constant".
Yes, it does seem to work if the right side is a literal but I still
can't get it to work where the right side is a field.

DEFINE FILE xxxxx
SMARTY_PANTS/YYMD = EDIT(field); <==== does not work!
END
 

On the PC I have to use '2 APR 2002' to simulate 2002 (because I don't have
those cool Y2K features [yet?]), but how about if you UPCASEd the string
first?
 

'1 apr 02' is ambiguous, unless you know a priori how the date elements
are arranged.

Focus will accept the string if the elements match the order of date
elements in the receiving variable's declared format; and I believe
Focus will rearrange the elements if their form is unambiguous (i.e.,
the month is alpha and the year has 4 digits).
From: Michael Lazarski
Subject: Re: Converting a date format from an external file...

Jack,
Yes, I understand that concept. The point is that I don't believe the
data, as generated, is unambiguous. On top of that, Focus does not like
the dashes separating the date elements. So, either way, some work
needs to be done on that data itself before Focus can correctly
interpret the date.
 

'1 apr 02' is ambiguous, unless you know a priori how the date elements
are arranged.
Focus will accept the string if the elements match the order of date
elements in the receiving variable's declared format; and I believe
Focus will rearrange the elements if their form is unambiguous (i.e.,
the month is alpha and the year has 4 digits).
 

Has the Upper limit on the number of &VARIABLES per session increased
since 7.01 on MVS?

See 'Increased Field Buffer Size' in the installation manual. The
6.8 install guide reads, in part:

"The maximum size of any record handled by FOCUS is 16,384 bytes... It
is possible to increase the record buffer from 16K bytes up to a
maximum of 32K bytes in increments of 4K bytes.

"...the number of Dialogue Manager variables allowed is dependant on
the size of the record buffers. The default size of 16K allows 512
Dialogue Manger variables (about 40 of these are reserved by FOCUS).
Each additional 4K added to the record buffer size will increase the
number of Dialogue Manager variables by 128, allowing a maximum of
1024 variables when the record buffer is set to 32K.

"The total length of all Dialogue Manager varables must also fit
within the record buffer size. With 16K buffers, we could have 512
variables of 32 bytes each or only 163 variables where the average
length was 100 bytes (16,300 bytes us ed of the total of 16*1024)."

Dialogue Manager uses two buffer areas: DATREC and LINREC, the same
areas used by MODIFY and TABLE for data manipulation. 32 bytes per
variable are stored in DATREC, which includes information about the
variable: name, type, length, and position in LINREC. The data value
is stored in LINREC. As quoted, the number of variables is limited
by two things: a maximum number of variables (buffer size/32) and
a maximum size basee on the sum of the lengths of all variables.

This dsicussion answers another question: Why can't I use amper
variables dynamically in a compiled MODIFY?

Amper variables are stored in the same location as MODIFY transactions
(DATREC and LINREC). As a FOCEXEC is parsed, all amper variables used
in the MODIFY are substituted and the code is moved to the FOCSTACK.
When -RUN is encountered, the Dialogue Manager contents of LINREC and
DATREC are moved to a special area in the FOCSTACK (they are restored
after control returns to Dialogue Manager). The amper variables are no
longer available (in their original format) when MODIFY is executing.
So, variables cannot be substituted in compiled MODIFY because they
can not be accessed.
It would be a major undertaking to rewrite FOCUS so that the variable
values would be available during MODIFY.
Rob Freeman
 

Converting a Packed Date Field to a Smart Date

Reply From Craig Kozlow,

First, DEFINE the packed field into a "recognizable" Old Date format...Then
convert that date to a Smart Date. I've found this to be the safest
conversion technique across platforms.

For example, given a Database with PAY_DATE existing as a PACKED field with a
usage format of P8, use the following DEFINE and TABLE....

DEFINE FILE anyfile
OLD/I8YYMD = PAY_DATE;
NEW/YYMD = OLD;
INEW/I8 = NEW;
END

TABLE FILE anyfile
PRINT PAY_DATE OLD NEW INEW
END
 

... to produce the following results...

PAY_DATE OLD NEW INEW
----------------- --------------- ---------------- ---------
20020202 2002/02/02 2002/02/02 36923
19991231 1999/12/31 1999/12/31 36159
19970202 1997/02/02 1997/02/02 35097
 

The INEW field is just to show the internal representation of the Smart Date,
NEW.

Craig Kozlow
Principal Consultant
Pinnacle Decision Systems, Inc.
 

JOIN CHANGES FOR Y2K

TABLE FILE DATAFILE
PRINT xxxx
BY FORMNO
ON TABLE HOLD AS H1
END

TABLE FILE H1
PRINT xxx
BY zzz
ON TABLE HOLD AS H2
END

TABLE FILE H2
PRINT yyy
BY FORMNO
ON TABLE HOLD AS H3
END

TABLE FILE DATAFILE
PRINT xxxx
BY FORMNO
ON TABLE HOLD AS H1
END

JOIN FORMNO IN H1 TO FORMNO IN H3 AS VJ

TABLE FILE H1
PRINT xxx
BY yyyy
ON TABLE HOLD AS H5
END

Now the DATAFILE is defined in the MFD, and has SUFFIX=FIX,
with one of the fields as FORMNO. FORMNO has a usage of A9,
Actual=A9.It has as it's first two characters a YEAR.
I would like to know how to replace the original JOIN
command.After I DEFINE a temporary field FORMNO_CY (with century
based on the window logic and the year)
I am in Rel 6.8.The manual does not say anything
on the crossreferenced field being a DEFINEd field.
THANKS very much in advance!
 

Reply From Art Greenhaus :-
I think that I might be misunderstanding you. You extract data and post-process
it, then do a subsequent extract and want to JOIN the subsequent extract to the
post-processed extract. BUT, you have a DEFINE on the post-processed extract,
and want to JOIN to it. Is that correct??

If so, then there are a few things to mention. First, you CAN'T JOIN to a
DEFINEd field, especially in a flat file. Why not issue your DEFINE before the
final stage of you post-processing extract?

Second, JOIN requires matching field values in both the 'from' and 'to' files.
If you changed the format and value of the 'to' field, you'd ALSO need to
change it in the 'from' file.

Reply FROM: Randy Gleason

SUBJECT: JOIN CHANGES,FOR Y2K
You cannot use a defined field in the cross referenced file portion
of a join (file h3 in this instance). Only the join from file
may have a defined field in the join (h1 in this instance). To
use a define field in a join the define must be declared after
the actual join as join clears all defines. But from the looks
of it you're creating the H3 file earlier in your procedure so
that would be the place to make your FROMNO field a four digit year.
When held as file H3 the field will then be a real field and could
be joined to.
 

Further Question: Re JOIN
My question was how do I issue a JOIN command when both the
'from' & the 'to' files are HOLD files from the same base file,
so if I DEFINE a temporary field and subsequently HOLD the file as
ON TABLE HOLD AS H3, the temporary fields DEFINEd are also stored
as real fields.Have I got it right?
I will also test this soon.

Yes, DEFINEd fields and real fields, once extracted to a HOLD file, are
identical. Just remember, to JOIN to a field in a sequential file, the
file must be SORTED on that field.

Possible bugs in Focus due to Date limitation in 'c' :

I read that even C is non compliant as the
time construct time_t stores the time as number of seconds from
a base date and that it will work fine only till 2038.So if
FOCUS is coded in C , is there any likelyhood of it being
impacted due to limitaitions of C itself?
Can anyone at IBI clear this?

Reply :
I'm sure that the compiler and language will change by then, so that it
will not be a problem.
From Art.
Reply From Rob Freeman.

FOCUS uses dates as a displacement in days, not seconds. It retrieves
date and time from the operating system already converted from
whatever offset the operating system is using.

There is no impact on FOCUS from this limitation in C.
 

Re: JOIN Further Questions...
I am in the process of Y2K conversion,and would like to know if the
following code is Y2K compliant,

Case1) JOIN DATE1 IN FILE1 WITH DATE2 IN FILE2
Assuming DATE1 & DATE2 are A6 dates.
The subsequent TABLE Request does not sort on the date field.
Eg,
TABLE FILE FILE1
PRINT X Y Z
BY A
END
Where X ,Y are in file1 and A & Z are in file2.

Case 2) Also, if in a subsequent TABLE request, if the report
was sorted on DATE1,

like,
TABLE FILE FILE1
PRINT X Y
BY DATE1
END
Please let me know how to go about with the conversion in either
of the cases.

First off, any A6 'date' is not Y2K compliant, as there's no indication as to
the century digits. As for sorting, the field is an A6 (the YMD just provides
output options), so it's sorted as an alphanumeric. Assuming it's A6YMD, it
SHOULD be chronological, but that means a year 00 will sort BEFORE a year 99.

If you convert these dates to a 'smart date', then the sort will be
chronological, and the century indication will be available, making it Y2K
compliant.

Reply By Art Greenhaus.
   There are more questions in the Next page !