Conference iosg::all-in-1_v30

Hi,

Thanks for your replies:

Re .1 No keyfield

Re .2  Version 3.0-1

Key field is username
Other fielda are Badge,Skilled and HDATE


------------------------------------- TOP --------------------------------------
Form:    GLUSER_DATA
Library: DISK$USERS:[TALBOT.A1V24]USER.FLB;
--------------------------------------------------------------------------------

;;.TYPE;;

ENTRY /MODE=update

;;.FILE;;

gluser_data.dat,username

;;HDATE;;

/lang=nbs_date
------------------------------------ BOTTOM ------------------------------------

Here is my Script:

!gl.scp
!

!This is the code to convert the TO date into NBS
!ready for comparison and use in the RSE
!
get #tdate = "10-JAN-1993"
!
date_conver
t #tdateout,#tdate,3
date_convert #tdate2out,#tdateout,7
get #new_tdate = #tdate2out:6:2
!
!
!
!
!
!This is the code to convert the TO date into NBS
!ready for comparison and use in the RSE
!
get #fdate = "01-DEC-1983"
!
date_convert #fdateout,#fdate,3date_
convert #fdate2out,#fdateout,7
get #new_fdate = #fdate2out:6:2
!
!
!
!Now we have the 2 dates in the right format lets go and
!find what records match.
!the field .hdate is the Hire Date entered from the form
!gluser_data.
!
!for gluser_data with (.hdate gt #new_fdate) and (.hdate gt #new_tdate) do -
!       get .%whole
!
!OR let's get all records to see what is stored.
for gluser_data do get .%whole

    I have never had any problem storing NBS dates with the /LANGUAGE
    qualifier. In fact, I use it all the time in many different
    applications, some of which do exactly the same thing as you outline in
    .0 (accept date from ARG format, convert to NBS format, and then lookup
    a dataset for matching records -- see pages 477 to 480 of CTO for some
    code).
    
    One thing -- are the date fields specified as X(11) so that the data
    stored is something like 19930121000 (padded out with three trailing
    zeros). Sometimes the extra 3 bytes are important, at least, I seem to
    remember this being so...
    
    Tony

    ah...
    
    The field hdate should be in the form yyyymmdd so why are you creating
    a symbol with a format of yymmdd to do the lookup?
    
    Rick

    Also, doing numberic compares with NBS dates sometimes gets flaky.
    ALL-IN-1 has a maximum number size that it can handle for numberic and
    16 character nbs dates exceed this size. You might need a .hdate:6:2
    in your for function to get it to work right.
    
    Rick

Hi,

	I have defined the date field HDATE as 
99-AAA-9999. That's why I load the symbol #tdate with
this format, to simulate user input. Does this field
on FMS have to be defined as x(11) or x(16) then, to get
it working?


If so the language qualifier should have some 
documentation with it saying what date layouts are
valid for use with it!

Cheers for your help, ideas so far

-Trev

I tend to leave date fields as straightforward X(11) definitions.  I then use 
one of the calendar data sets to validate the input.  CAL$SET_DATE does a 
good job, and OA$DATE isn't bad either.  The stuff in the field might be 
interfering with the NBS format being stored, but I don't really know without 
some testing.  Try some X(11) fields and see what happens.

T

Hi Tony,

	Thanks for your persistance on this; I modified
my date field to X11 and stuck the following named
data on the date field:

;;HDATE;;
/LANGUAGE=NBS_DATE/VALID=CAL$SET_DATE:"HDATE"

this now stores the data in the correct format, I only 
have to convince the customer to change his form!

Cheers,

-Trev