![]() |
||||||||||||
Go ![]() | New ![]() | Search ![]() | Notify ![]() | Tools ![]() | Reply ![]() | ![]() |
Master |
Is there a date/?? format for May-14 (May 2014)? Thank youThis message has been edited. Last edited by: FP Mod Chuck, Tomsweb WebFOCUS 8.1.05M, 8.2.x APP Studio, Developer Studio, InfoAssist, Dashboards, charts & reports Apache Tomcat/8.0.36 | ||
|
Master |
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
| ||||||||||||||
|
Master |
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
| ||||||||||||||
|
Master |
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
| ||||||||||||||
|
Virtuoso |
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 WF versions : Prod 8.2.0.1M gen 240, Dev 8.2.04 gen 48, OS : Windows, DB : MSSQL, Outputs : HTML, Excel, PDF In Focus since 2007 | |||
|
Master |
Thank you MartinY and Hallway. With a clear mind I came up with this:
Tomsweb WebFOCUS 8.1.05M, 8.2.x APP Studio, Developer Studio, InfoAssist, Dashboards, charts & reports Apache Tomcat/8.0.36 | |||
|
Virtuoso |
@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 WF versions : Prod 8.2.0.1M gen 240, Dev 8.2.04 gen 48, OS : Windows, DB : MSSQL, Outputs : HTML, Excel, PDF In Focus since 2007 | |||
|
Master |
His code is fine. I was just trying to take initiative. I can certainly use his code . Tomsweb WebFOCUS 8.1.05M, 8.2.x APP Studio, Developer Studio, InfoAssist, Dashboards, charts & reports Apache Tomcat/8.0.36 | |||
|
Virtuoso |
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 WF versions : Prod 8.2.0.1M gen 240, Dev 8.2.04 gen 48, OS : Windows, DB : MSSQL, Outputs : HTML, Excel, PDF In Focus since 2007 | |||
|
Gold member |
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. IBI Development | |||
|
Powered by Social Strata |
![]() | Please Wait. Your request is being processed... |
|