Impacts of modifying record structures

[Edis, Bob]

Has the definition for T-NEW-ENTRY changed?   How is it declared on each
screen?

I assume the receiving screen was always a MENU screen.

I tend to agree with a previous poster; you will have to recompile the
screens that reference this record.

Blue

-----Original Message-----
From: pablo grim [mailto:pablow666@gorge.net]
Sent: Monday, July 23, 2001 3:54 PM
To: Edis, Bob; 'powerh-l@list.swau.edu'
Subject: Re: Impacts of modifying record structures


Sure.  Here's a typical example:


RUN SCREEN HRS_EXE:HRNK096.QKC MODE SAME PASSING EMPLOYEE-PER, T-NEW-ENTRY

SCREEN HRS_EXE:HRNK096.QKC  MENU RECEIVING EMPLOYEE-PER, T-NEW-ENTRY &
       MESSAGE ON 24

I tried the "substructure" approach on the record statement rather than
shortening the filler field, but I am still getting the same error message.

Here are the items in question after substructuring.  The country code field
is the new item.  CLIENT-ELEMENT is the filler item:

    CLIENT-ELEMENT                       CHARACTER         40          295
    .FOREIGN-COUNTRY-CODE                CHARACTER          2          295
    DATE-LONGEVITY-LAST                  INTEGER SIGNED     4          335

The file is indexed sequential RMS.

Is there some way I could do it with a REDEF?  I am playing around with it,
but it increases the record length...

tx

p
> From: "Edis, Bob" <bob.edis@fleetpride.com>
> Date: Mon, 23 Jul 2001 14:54:00 -0500
> To: "'powerh-l@list.swau.edu'" <powerh-l@lists.swau.edu>
> Subject: RE: Impacts of modifying record structures
> 
> Pablo
> 
> Can we see the subscreen/run screen statements from the calling screen and
> the screen statement from the receiving screen please?
> 
> Regards,
> Blue
> 
> -----Original Message-----
> From: pablo grim [mailto:pablow666@gorge.net]
> Sent: Monday, July 23, 2001 2:42 PM
> To: powerhouse
> Subject: Impacts of modifying record structures
> 
> 
> Howdy folks,
> 
> Ok, I have a record structure called EMPLOYEE-PER that is used in about a
> zillion programs.  The record structure includes "filler" fields for
future
> expansion.  This is handy to avoid having to recompile everything when
> adding a new item to the record structure.  Simply take some bytes from
the
> filler and use them for the new item.  Therefore, the record length stays
> the same.  I'm sure most of you have done something similar.
> 
> Well, I did this, but I'm getting the error:
> 
> *d* The screen linkage parameters don't agree with local definitions.
> 
> when I call a subscreen passing the EMPLOYEE-PER record.  This is
> disappointing as it looks like I will have to recompile every subscreen
that
> receives this record structure as a parameter (a very significant task).
I
> don't remember this happening before when using this old tried and true
> technique for avoiding recompiles.  Is this something new?
> 
> Does anybody have any suggestions for modifying my record structure
without
> having to recompile?  All I am trying to do is add a new 2 character field
> to the record.  The "filler" field that I have shortened is not a
parameter
> being passed to the subscreens.
> 
> VMS 7.1
> PH    7.10
> RMS files
> 
> thanks!
> 
> p 
> 
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe" in message body to
> powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a subscriber.
> 
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a subscriber.