Is there a date/?? format for May-14 (May 2014)?


Thank you

This message has been edited. Last edited by: FP Mod Chuck,

If you use DATE/MtY it will give you the format May, 14. If you need to change the delimiter, then check out the docs on DATETRAN

IMHO, the docs aren't very clear, and are really hard to follow However, I was able to get it to the format you requested in the sample fex below

 
DEFINE FILE ggsales
DATE1/MtY = DATE;
DATE2/A6 = DATETRAN(DATE1, '(MY)','(-t)', 'EN', 6, 'A6');
END
TABLE FILE ggsales
BY DATE
BY DATE1
BY DATE2
END
 

Looks like this works as well

  
DEFINE FILE ggsales
Month-Year/A6 = DATETRAN( DATECVT( DATE, 'I8YYMD', 'MY' ), '(MY)', '(-t)', 'EN', 6, 'A6');
END
TABLE FILE ggsales
BY DATE
BY Month-Year
END

LOL... I'm always on a quest to shorten the lines of code 🤓

  
TABLE FILE ggsales
SUM COMPUTE Month-Year/A6 = DATETRAN( DATECVT( DATE, 'I8YYMD', 'MY' ), '(MY)', '(-t)', 'EN', 6, 'A6');
BY DATE
END

quote:

Originally posted by Hallway:
LOL... I'm always on a quest to shorten the lines of code 🤓

  
TABLE FILE ggsales
SUM COMPUTE Month-Year/A6 = DATETRAN( DATECVT( DATE, 'I8YYMD', 'MY' ), '(MY)', '(-t)', 'EN', 6, 'A6');
BY DATE
END

The above does work because you only have the BY DATE, but if it is as below, only one date from each CITY will be displayed and depending one data organization it may be any one.
So, when using a COMPUTE to shorten the lines of code you need to pay attention at the result and desired result.

TABLE FILE ggsales
SUM COMPUTE Month-Year/A6 = DATETRAN( DATECVT( DATE, 'I8YYMD', 'MY' ), '(MY)', '(-t)', 'EN', 6, 'A6');
BY CITY
-*BY DATE
END

Thank you MartinY and Hallway. With a clear mind I came up with this:


TABLE FILE EMPLOYEE
PRINT
COMPUTE MONTH4/Mt = HIRE_DATE;
COMPUTE THEMONTH/A3 = FPRINT(MONTH4, 'Mt', 'A3');
COMPUTE YEAR2/Y = HIRE_DATE;
COMPUTE YR/A2 = EDIT(YEAR2);
COMPUTE HDDATE/A10 = THEMONTH || '-' || YR;

BY EMPLOYEE.EMPINFO.HIRE_DATE
ON TABLE NOTOTAL
ON TABLE SET STYLE *
$
ENDSTYLE
END


@Tomsweb

Just a question : why not have used Hallway simplified coding ? Much less lines of code...

TABLE FILE EMPLOYEE
PRINT COMPUTE HDDATE/A10 = DATETRAN( DATECVT( HIRE_DATE, 'I8YYMD', 'MY' ), '(MY)', '(-t)', 'EN', 6, 'A6');
BY EMPLOYEE.EMPINFO.HIRE_DATE
ON TABLE NOTOTAL
ON TABLE SET STYLE *
$
ENDSTYLE
END

His code is fine. I was just trying to take initiative. I can certainly use his code .

quote:

Originally posted by Tomsweb:
I was just trying to take initiative.

This is perfect but you should also take initiative to simplify and optimize your code.

Having 5 COMPUTEs and 4 functions (FPRINT, EDIT and twice the double pipe) used is less efficient than 1 COMPUTE and 2 functions

Just me 2 cent

Here is a third way to do this:

INDATA/A8YYMD WITH DVAL = '&YYMD' ;
MYM/A2 = EDIT(INDATA,'$$$$99');
MYMT/A3 = DECODE MYM(01 Jan 02 Feb 03 Mar 04 Apr 05 May 06 Jun
                     07 Jul 08 Aug 09 Sep 10 Oct 11 Nov 12 Dec ELSE ???);
MYD/A2 = EDIT(INDATA,'$$99');
MYMYR/A6 = MYMT | '-' | MYD ;
 

This technique uses no functions (EDIT is not really a function, but rather a compiled construct).

Just for fun, here is a benchmark that compares all three techniques for efficiency:

-DEFAULTS &FLD=MYEAR,&RECLIM=20000
DEFINE FILE SMALL
INDAT/I8YYMD WITH DVAL = &YYMD;
INDATA/A8YYMD WITH DVAL = '&YYMD' ;
INA/A6       WITH DVAL = 'Aug-19';
INYYMD/YYMD  WITH DVAL = &YYMD;
MYEAR/A6 = DATETRAN( DATECVT ( INDAT, 'I8YYMD', 'MY' ), '(MY)', '(-t)', 'EN', 6, 'A6');

MONTH4/Mt = INYYMD;
THEMONTH/A3 = FPRINT(MONTH4, 'Mt', 'A3');
YEAR2/Y = INYYMD;
YR/A2 = EDIT(YEAR2);
HDDATE/A10 = THEMONTH || '-' || YR;

MYM/A2 = EDIT(INDATA,'$$$$99');
MYMT/A3 = DECODE MYM(01 Jan 02 Feb 03 Mar 04 Apr 05 May 06 Jun
                     07 Jul 08 Aug 09 Sep 10 Oct 11 Nov 12 Dec ELSE ???);
MYD/A2 = EDIT(INDATA,'$$99');
MYMYR/A6 = MYMT | '-' | MYD ;
END
-RUN

-TYPE First, get the base benchmark.
-SET &MYCPU = &FOCCPU ;
TABLE FILE SMALL
SUM INA
IF RECORDLIMIT EQ &RECLIM
END
-RUN
-SET &DIFF = &FOCCPU - &MYCPU ;
-TYPE CPU BASE: &DIFF

-TYPE Now, the MYEAR technique:
-SET &MYCPU = &FOCCPU ;
TABLE FILE SMALL
SUM MYEAR
IF RECORDLIMIT EQ &RECLIM
END
-RUN
-SET &DIFF = &FOCCPU - &MYCPU ;
-TYPE CPU MYEAR: &DIFF
-TYPE Next, the HDDATE technique:
-SET &MYCPU = &FOCCPU ;
TABLE FILE SMALL
SUM HDDATE
IF RECORDLIMIT EQ &RECLIM
END
-RUN
-SET &DIFF = &FOCCPU - &MYCPU ;
-TYPE CPU HDDATE: &DIFF

-TYPE Finally, the MYMYR technique (no functions)
-SET &MYCPU = &FOCCPU ;
TABLE FILE SMALL     
SUM MYMYR
IF RECORDLIMIT EQ &RECLIM
END
-RUN
-SET &DIFF = &FOCCPU - &MYCPU ;
-TYPE CPU MYMYR: &DIFF
 

The SMALL file is just a file with 20000 short records, with the DVAL field in the segment that has 20000 records. You can substitute your own SMALL file with your own 'WITH' field, and the benchmark will work.

Here is the result on a zos mainframe:

>>ex test
First, get the base benchmark.
 PAGE     1
 
 
 INA                                                                           
 ---                                                                           
 Aug-19
 
 
CPU BASE: 59 
Now, the MYEAR technique:  
 PAGE     1
 
 
 MYEAR                                                                         
 -----                                                                         
 Aug-19
 
 
CPU MYEAR: 147 
Next, the HDDATE technique:  
 PAGE     1
 
 
 HDDATE                                                                        
 ------                                                                        
 Aug-19    
 
 
CPU HDDATE: 139 
Finally, the MYMYR technique (no functions)  
 PAGE     1
 
 
 MYMYR                                                                         
 -----                                                                         
 Aug-19
 
 
CPU MYMYR: 56 
 

So, what does this tell us? The base benchmark is 59ms. This represents the overhead of reading the file, collecting the alpha value, and printing the report. It essentially does nothing.

The MYEAR technique took 147ms total, and subtracting the base, about 88ms.
The HDDATE benchmark took 139ms total, or about 80ms.
The MYMYR benchmark took 56ms total, or, wait- it was *faster* than the base! This happened because in reality, the MYMYR overhead is essentially unmeasureable compared to the base, and is smaller than the normal benchmark variation from one execution to the next. Probably, MYMYR is dozens if not hundreds of times faster than the other two techniques.

So, why is MYMYR so fast? Because it does not use any functions, and the DEFINE code is actually compiled into very fast native zos instructions without any subroutine calls.

So, in general, if you *really* want fast code, avoid function calls and just use FOCUS computations.