TIME Macro Expansion 
Author Message
 TIME Macro Expansion

Just for kicks I expanded the TIME Macro as follows and got:

          TIME MIC,TDATE,ZONE=GMT,LINKAGE=SYSTEM,DATETYPE=MMDDYYYY  
+         MACDATE       05/04/90
+         DS    0H
+         LAE   1,0(0,0)        ZERO ACCESS REGISTER 1
+         LA    1,IHB0004D      POINT TO PARAMETER LIST
+         B     IHB0004W        BRANCH AROUND LIST
+IHB0004D DS    0F
+         DC    FL2'0'
+         DC    FL1'0'
+         DC    FL1'0'
+         DC    2F'0'
+         DC    2F'0'
+         DC    2F'0'
+IHB0004W DS    0H
+         MVI   3(1),131        TIME FLAGS INTO P LIST
+         MVI   2(1),1          DATE FLAGS INTO P LIST
+         L     14,16(0,0)      CVT ADDRESS
+         L     14,772(14,0)    SFT ADDRESS
+         L     14,304(14,0)    LX/EX FOR SERVICE ROUTINE
+         PC    0(14)
+         LAE   14,TDATE        ADDRESS OF USER'S AREA
+         MVC   0(16,14),12(1)  MOVE OUTPUT FROM PARM LIST
+*                              TO THE USER'S AREA

No copyright notice in the expansion so I guess it's ok to show it
here.     -----------------------------------------------------

This code is in an operational program in a radar system I am working on
and I wanted to see how it could be detected and I wanted to look at the
code that processed the returned data. It's MVS/ESA.

I thought someone said there was an SVC 11 in here but this uses a plain
old PC. A little bit harder to find unless you have source code to scan.
Looks like IBM buried the clock code in the service routine. Great.

In this particular case it doesn't matter much because the code that
follows this macro totally ignores the 4-digit year anyway.

Jim

--
James E. Smith, Jr.



Wed, 01 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion

James E. Smith, Jr. writes ...

<< Just for kicks I expanded the TIME Macro as follows and got:

          TIME MIC,TDATE,ZONE=GMT,LINKAGE=SYSTEM,DATETYPE=MMDDYYYY  
+         MACDATE       05/04/90
+         DS    0H
+         LAE   1,0(0,0)        ZERO ACCESS REGISTER 1
+         LA    1,IHB0004D      POINT TO PARAMETER LIST
+         B     IHB0004W        BRANCH AROUND LIST
+IHB0004D DS    0F
+         DC    FL2'0'
+         DC    FL1'0'
+         DC    FL1'0'
+         DC    2F'0'
+         DC    2F'0'
+         DC    2F'0'
+IHB0004W DS    0H
+         MVI   3(1),131        TIME FLAGS INTO P LIST
+         MVI   2(1),1          DATE FLAGS INTO P LIST
+         L     14,16(0,0)      CVT ADDRESS
+         L     14,772(14,0)    SFT ADDRESS
+         L     14,304(14,0)    LX/EX FOR SERVICE ROUTINE
+         PC    0(14)
+         LAE   14,TDATE        ADDRESS OF USER'S AREA
+         MVC   0(16,14),12(1)  MOVE OUTPUT FROM PARM LIST
+*                              TO THE USER'S AREA

No copyright notice in the expansion so I guess it's ok to show it
here.     -----------------------------------------------------

This code is in an operational program in a radar system I am working on
and I wanted to see how it could be detected and I wanted to look at the
code that processed the returned data. It's MVS/ESA.

I thought someone said there was an SVC 11 in here but this uses a plain
old PC.   [snip]  >>

The LINKAGE=SYSTEM parameter is what generates the PC; if you omit the
parameter and get the default option LINKAGE=SVC, then you would see the
SVC 11 instruction.

Regards,

Steve Comstock
Telephone: 303-393-8716

256-B S. Monaco Parkway
Denver, CO 80224
USA



Thu, 02 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion

Quote:

> James E. Smith, Jr. writes ...
. . . . . (snip)
>> I thought someone said there was an SVC 11 in here but this uses a plain
>> old PC.   [snip]  >>

> The LINKAGE=SYSTEM parameter is what generates the PC; if you omit the
> parameter and get the default option LINKAGE=SVC, then you would see the
> SVC 11 instruction.

. . . . . (snip)

Right, but LINKAGE=SVC is only provided for backward compatibility.
LINKAGE=SYSTEM is the preferred parameter.

regards Sven



Fri, 03 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion

Your expansion was the result of LINKAGE=SYSTEM, as opposed to LINKAGE=SVC.  The following discussion shows a usage of the olde (pre PC) LINKAGE=SVC (the default).

The IBM MVS TIME SVC year 2000 trap.

In about 1982, IBM changed the definition of the date returned by the MVS TIME SVC to add a century indicator.  

The date is returned in general register 1 as packed decimal in the form CCYYDDDF, where:                              
       CC  - is the century                <==== added in the early 1980's          
       YY  - is the last two digits of the year
       DDD - is the day of the year
       F   - allows for unpacking

Prior to the change, the value returned was 00YYDDDF.

To make the change as "transparent" as possible, the CC century indicator was defined as 00 for years beginning with 19, and 01 for years beginning with 20, etc.  While there may be screams about this approach today, it is fact, and has been for 15 years or so...

Existing programs were not affected in 1983.  They issued the TIME SVC and retrieved dates such as 0083123F.  They continued to work just fine, so nobody bothered to change anything...

Code such as this example:

         TIME  DEC
         ST    R0,TIME             SAVE TIME
         ST    R1,DATE             SAVE DATE
         MVO   TIM,TIME(2)         SAVE TIME
         MVC   HLINE90,PAT01   INSERT PATTERN FOR EDIT
         ED    HLINE90,DATE+1  EDIT DATE  YY.DDD
         MVC   HLINE82,=C'DATE:  19' LABEL AND CENTURY 19
         MVC   HLINE70,PAT03   INSERT PATTERN FOR EDIT
         ED    HLINE70,TIM     EDIT TIME  HH.MM
         MVC   HLINE63,=C'TIME:' LABEL FOR TIME

 HLINE   DC    CL132' '            
         ORG   HLINE+63
 HLINE63 DS    CL5                     TIME: LABEL
         DS    CL2
 HLINE70 DS    CL7                     TIME PATTERN GOES HERE
         DS    CL5
 HLINE82 DS    CL9                     DATE: LABEL PLUS CONSTANT 19
         ORG   HLINE+90
 HLINE90 DS    CL7                     DATE PATTERN HERE
         ORG   ,                      

 PAT01   DC    XL7'4021204B202020' BLANK FILL CHAR,
 *                                 SIGNIFICANCE STARTER DIGIT, DIGIT
 *                                 PERIOD, DIGIT, DIGIT, DIGIT
 PAT03   DC    XL7'402120204B2020' BLANK, DIGIT, FORCED DIGIT,
 *                                 PERIOD, DIGIT, DIGIT
 TIME    DC    F'0'                UNSIGNED TIME VALUE
 TIM     DC    X'00000F'           USED TO ADD SIGN TO TIME
 DATE    DC    F'0'                TIME SVC DATE 00YYDDDF

worked just time, producing values like

 Returned date value X'0097074F'

 TIME:    18.14     DATE:  1997.074

but, when January 01, 2000 rolls around, this code will yield

 Returned date value X'0100001F'

 TIME:    18.14     DATE:  19 0.001

probably not the behavior the original author had in mind.

Bear in mind that this example is very innocent, as it only affected a heading line, not any critical calculation.  The casual observer of the output in 1999 or before, might even think that the report is Y2K compliant, since the presented date has a 4 digit year.

The fix is not to complex, assuming that the real desire is to have accurate 4 digit years.

         TIME  DEC                
         ST    R0,TIME             SAVE TIME
         ST    R1,DATE             SAVE DATE                
*        CONSTRUCT 4 DIGIT YEAR FROM TIME SVC DATE
         AP    DATE,=P'1900000'    MAKE CENTURY REAL             Y2K
         MVO   TIM,TIME(2)         SAVE TIME
*        INCREASE SIZE OF PATTERN TO ALLOW FOR 4 DIGIT YEAR      Y2K
         MVC   HLINE88,PAT01    SET UP DATE YYYY.DDD PATTERN     Y2K
         ED    HLINE88,DATE  EDIT DATE YYYY.DDD                  Y2K
         MVC   HLINE82,=C'DATE: ' IDENTIFIER ONLY                Y2K
         MVC   HLINE70,PAT03    SET UP TIME HH.MM PATTERN      
         ED    HLINE70,TIM     EDIT TIME  HH.MM        
         MVC   HLINE63,=C'TIME:'   IDENTIFIER ONLY

HLINE    DC    CL132' '
         ORG   HLINE+63
HLINE63  DS    CL5                     TIME: LABEL
         DS    CL2
HLINE70  DS    CL7                     TIME PATTERN GOES HERE
         DS    CL5
HLINE82  DS    CL6                     DATE: LABEL                Y2K
HLINE88  DS    CL9                     DATE PATTERN HERE          Y2K
         ORG   ,                      

PAT01    DC    XL9'40212020204B202020' BLANK FILL CHAR,
*                                      SIGNIFICANCE STARTER DIGIT,   Y2K
*                                      DIGIT, DIGIT, DIGIT, PERIOD   Y2K
*                                      DIGIT, DIGIT, DIGIT
PAT03    DC    XL7'402120204B2020'     BLANK FILL CHAR,
*                                      SIGNIFICANCE STARTER DIGIT,
*                                      DIGIT, PERIOD, DIGIT, DIGIT
TIME     DC    F'0'                TIME SVC DEC TIME VALUE
TIM      DC    X'00000F'           TIME SVC DEC HH.MM WITH SIGN
DATE     DC    F'0'                TIME SVC CCYYDDDF               Y2K

Only a single instruction was added, one edit mask was altered, one literal was shortened to remove the forced 19', and the target location of the edit was adjusted.

With this change the results are:

 Returned date value X'0097074F'

 TIME:    18.14     DATE:  1997.074

when January 01, 2000 rolls around, this code will yield

 Returned date value X'0100001F'

 TIME:    18.14     DATE: 2000.001

probably much closer to the behavior the original author had in mind.

Big problem is not how to fix the problem, but rather how to locate the exposures.

Significant points:

1.  This code pattern is only an issue in Assembler based applications.  High level applications have their own fun games (especially if the library routines have similar bugs).

2.  How do you find how much assembler you have in inventory?  Especially those innocent routines written by the system programmer who left the company in 1972, are used by dozens or hundreds of programs, and are still in service today.

3.  How do you determine if the assembler code in inventory has TIME SVC's in it?

4.  How to evaluate the situation and fix the code once you find the problem cases?

Sure, you can look thru tens of thousands of source listings and linkage edits from the last 28 years (you did keep all of them didn't you?)....

Or (merely a blatant commercial) you can find the assembler components in your inventory quickly and mechanically by using the Edge Portfolio Analyzer.  This knowledge based tool reads you load module libraries, and classifies every CSECT of every load module in each library that it processes.  This process initially produces an inventory at the library, loadmodule and CSECT basis.  All assembler components are identified.

So what, you say, I now have a list of tens of thousands of assembler CSECTs spread across hundreds of load module libraries....  Experience has shown that programs of this class frequently are service routines called by hundreds of programs.  By consolidating all observations of the routines based on identical CSECT name, compile date, size (you did re-link every program that used the subroutine each time the subroutine was updated didn't you?), you can typically greatly reduce the further research required.

So, I am now down to hundreds of programs, IT'S STILL TOO MUCH WORK.  Well... calm down, you have not gotten to the good part yet.  The Edge Portfolio Analyzer knows all about TIME SVC code patterns (as well as STCK - store clock instruction), and provides a listing showing the location (displacement within CSECT) of each probable instance of the TIME SVC or STCK instruction in the inventory.

You have now solved points 1, 2 and 3.  Time, typically less than a day for hundreds of libraries.  Processing time is in the range of thousands of load modules per elapsed hour.  Typically JCL preparation, and output examination takes far more time than actual execution.

Oh Gee....  Now I can spend my resources on actually looking at code and fixing the problems, instead of chasing geese looking for possible issues.  

Some details on the Edge Portfolio Analyzer at HTTP://WWW.EDGE-INFORMATION.COM

Rex Widmer
Builder of software archeology tools and other strange programs to help survive in a legacy based world.



Fri, 03 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion

Quote:


> > James E. Smith, Jr. writes ...
> . . . . . (snip)
> >> I thought someone said there was an SVC 11 in here but this uses a plain
> >> old PC.   [snip]  >>

> > The LINKAGE=SYSTEM parameter is what generates the PC; if you omit the
> > parameter and get the default option LINKAGE=SVC, then you would see the
> > SVC 11 instruction.
> . . . . . (snip)

> Right, but LINKAGE=SVC is only provided for backward compatibility.
> LINKAGE=SYSTEM is the preferred parameter.

> regards Sven

Plus LINKAGE=SYSTEM is in existing operational code. It would take an
act of Congress (exaggeration) to get it changed. And the only reason I
know it's LINKAGE=SYSTEM is because I was fixing another area of the
source code that contained this reference. In this case I have total
access to all the source code but that's a fairly rare condition.

What about the offsets for CVT, SFT, and LX/EX? Are those Release or PTF
dependent? If so, then the "preferred" method makes it hard to write a
scanner that will pick up the TIME macro expansion in object or load
module. Wait a minute! We can just ask IBM for the complete list of
offsets and they should be able to respond before zero hour, shouldn't
they?

Otherwise we will have to either just wait for code to break and get
dumps or have folks put their proprietary source code back on the system
so we can scan for "TIME" and "LINKAGE=SYSTEM".

Does anyone know if the Edge Portfolio Analyzer can find these
occurrences, in object or load module, where LINKAGE=SYSTEM?

Jim

--
James E. Smith, Jr.
"And so they said it couldn't be done. So we did it anyway."



Fri, 03 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion

EPA can currently (and for several years) find TIME SVC's, the expansion of  old format TIME and new format TIME ... LINKAGE=SVC.  

It also finds STCK instructions.

EPA does not currently look for TIME .... LINKAGE=SYSTEM; it could be added in a few days if any customer wants it.  Reasoning was that LINKAGE=SYSTEM did not show up until MVS 4.x (as I recall), and LINKAGE=SYSTEM will return a specified format of date such as the example shown with a 4 digit year in this thread.

All of the defects that we have found (yup we have not looked terribly hard for LINKAGE=SYSTEM) involved SVC 11 - the expansion of TIME or TIME LINKAGE=SVC.  This includes extensive source scans as well as executions of EPA.

Of course one could use code like:

     LA R3,11   value to overlay 2nd byte of executed instruction
     LA R1,x     SVC 11 parm
     LA R0,y     SVC 11 parm
     EX R3,SVC0   sneaky way to issue SVC 11

SVC0  SVC 0    ** executed **

and nothing but GTF will find this, and then only at the instant of execution.

Rex Widmer
Builder of software archeology tools and other strange programs to help survive in a legacy based world.



Sat, 04 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion


Quote:
>What about the offsets for CVT, SFT, and LX/EX? Are those Release or PTF
>dependent? If so, then the "preferred" method makes it hard to write a
>scanner that will pick up the TIME macro expansion in object or load
>module. Wait a minute! We can just ask IBM for the complete list of
>offsets and they should be able to respond before zero hour, shouldn't
>they?

>Otherwise we will have to either just wait for code to break and get
>dumps or have folks put their proprietary source code back on the system
>so we can scan for "TIME" and "LINKAGE=SYSTEM".

>Does anyone know if the Edge Portfolio Analyzer can find these
>occurrences, in object or load module, where LINKAGE=SYSTEM?

>Jim

>--
>James E. Smith, Jr.
>"And so they said it couldn't be done. So we did it anyway."


Rex says yes.  Or at least that's how I interpret an email he sent me.
Anyway a guy who calls himself a software archeologist has to be able to
do this with a camel's hair brush and tiny picks.

Cory Hamasaki      http://www.kiyoinc.com
HHResearch Co.     OS/2 Webstore & Newsletter
REDWOOD        



Sat, 04 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion

Quote:

>snip...
> All of the defects that we have found (yup we have not looked terribly hard for LINKAGE=SYSTEM) involved SVC 11 - the expansion of TIME or TIME LINKAGE=SVC.  This includes extensive source scans as well as executions of EPA.

> Of course one could use code like:

>      LA R3,11   value to overlay 2nd byte of executed instruction
>      LA R1,x     SVC 11 parm
>      LA R0,y     SVC 11 parm
>      EX R3,SVC0   sneaky way to issue SVC 11

> SVC0  SVC 0    ** executed **

> and nothing but GTF will find this, and then only at the instant of execution.

> Rex Widmer
> Builder of software archeology tools and other strange programs to help survive in a legacy based world.

Your right about the "hiding SVC 11" code but I don't think there will
be much of that. These guys probably had a hard enough time getting the
date processed without having to try to hide it.

In retrospect I can see that the LINKAGE=SYSTEM is a non-problem anyway
because IBM can easily fix that one in just one place (right? :)).

My other point was that the code that followed the TIME Macro, even
though the TIME parm is for a 4-digit year in the example, the
programmer simply ignored the first two digits anyway. I guess these
kind of problems will just have to be ferreted out one by one using the
classic labor intensive methodology of "troubleshooting" at whatever
rate you are charging per hour (slurp, slurp, run to bank, slurp,
slurp).
Shucks.                                                                                                                
--
James E. Smith, Jr.



Sat, 11 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion

Quote:

>...<big snip>
> Oh Gee....  Now I can spend my resources on actually looking at code and fixing the problems, instead of chasing geese looking for possible issues.

> Some details on the Edge Portfolio Analyzer at HTTP://WWW.EDGE-INFORMATION.COM

> Rex Widmer
> Builder of software archeology tools and other strange programs to help survive in a legacy based world.

Yup. The big problem is finding and filling all those little prairiedog
holes before your horse steps in one. But once you have gone through one
site the process should accelerate because you will have identified and
fixed routines common to other sites and you won't have to do those
again. And, of course, each site you do adds a little to that so that
after a bit you will just have to find and fix those "site specific"
problems. Yeah! Sounds like a good approach to me.

--
James E. Smith, Jr.



Sat, 11 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion

You would not be surprized how much code - especially assembler service routines - seems to appear at multiple shops.

One particular case that has been observed at multiple shops has now been nicknamed "the Hartford Disease".  Seems like there was either code sharing or an iterant assembler programmer going from one major insurer to another with the same code back in the early 70's.  The particular code was not date related, but implemented dynamic resolved calls in assembler for COBOL applications.  Worked just fine till LE/370 came along.  Now is a wonderfull business opportunity.

Rex Widmer
Builder of software archeology tools and other strange programs to help survive in a legacy based world.



Mon, 13 Sep 1999 03:00:00 GMT  
 TIME Macro Expansion

I just had occasion to use the TIME macro with FORMAT=YYYYMMDD, TIME=DEC and    
LINKAGE=SYSTEM.  This macro returns the time and date in a 16 byte area.  The    
format of returned value is x'hhmmssthxxxxxxxxyyyymmdd00000000' where    
xxxxxxxx refers to unknown garbage.  I did not have access to a manual at the    
time so I used the comments in SYS1.MACLIB.  If they were returning the    
information in an 8 byte area I could see the format of the data I could see    
the method but it was not an intuitive expectation.  Given that people are    
now using the macro as defined, I would hope that IBM would add a parameter    
TIME=CHAR to the macro so that the 16 byte area would receive an 8 character    
time followed by an 8 character date.    

Quote:


> >snip...  

> > All of the defects that we have found (yup we have not looked terribly    

hard for LINKAGE=SYSTEM) involved SVC 11 - the expansion of TIME or TIME    
LINKAGE=SVC.  This includes extensive source scans as well as executions of    
EPA.  
Quote:

> > Of course one could use code like:  

> >      LA R3,11   value to overlay 2nd byte of executed instruction  
> >      LA R1,x     SVC 11 parm  
> >      LA R0,y     SVC 11 parm  
> >      EX R3,SVC0   sneaky way to issue SVC 11  

> > SVC0  SVC 0    ** executed **  

> > and nothing but GTF will find this, and then only at the instant of    
execution.  

> > Rex Widmer  
> > Builder of software archeology tools and other strange programs to help    

survive in a legacy based world.  

Quote:

> Your right about the "hiding SVC 11" code but I don't think there will  
> be much of that. These guys probably had a hard enough time getting the  
> date processed without having to try to hide it.  

> In retrospect I can see that the LINKAGE=SYSTEM is a non-problem anyway  
> because IBM can easily fix that one in just one place (right? :)).  

> My other point was that the code that followed the TIME Macro, even  
> though the TIME parm is for a 4-digit year in the example, the  
> programmer simply ignored the first two digits anyway. I guess these  
> kind of problems will just have to be ferreted out one by one using the  
> classic labor intensive methodology of "troubleshooting" at whatever  
> rate you are charging per hour (slurp, slurp, run to bank, slurp,  
> slurp).  
> Shucks.                                                                                                                  
> --  
> James E. Smith, Jr.  


Clark F. Morris, Jr.  
CFM Technical Programming Services  
Bridgetown, Nova Scotia, Canada  




Tue, 14 Sep 1999 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. TIME Macro Expansion MVS/ESA

2. TIME Macro Expansion MVS/ESA

3. Macro expansion, times.

4. WTO macro expansion

5. More Macro Expansion Questions

6. macro expansion problem

7. Complicated macro expansion question

8. Macro expansion

9. An introduction to macro expansion algorithms, part 2

10. An introduction to macro expansion algorithms, part 1

11. An introduction to macro expansion algorithms, part 4

12. An introduction to macro expansion algorithms, part 3

 

 
Powered by phpBB® Forum Software