Wow.  I looked at a utility app I wrote several years ago and use every
day, but forgot the shenanigans I had to go through with the very issue
you are tackling.  In my case, this is a subfile app, and I have two sets
of SFLCTL, SFL, and "normal" command keys record, one each per display
mode.  As you will see in the SFLCTL records, it refers to both modes,
even though each SFLCTL record is designed for one of the two modes.  I
honestly don't recall why this is coded the way it is - it's just been too
long - so I can't say whether it is necessary, or whether it is a kludge
that I found that "just works" (so don't fix it) after hundreds of
attempts to get it to compile <g>.  The "kludge" may have been necessary
because of the subfiles, but I'm not sure.

At the file level:
   A                                      DSPSIZ(27 132 *DS4 -
   A                                             24 80 *DS3) 

At the record level (the last two digits of the record name indicate the
mode):
   A          R SFLCTL27                  SFLCTL(SFL27)
   A  *DS4                                SFLSIZ(0020) 
   A  *DS3                                SFLSIZ(0008) 
   A  *DS4                                SFLPAG(0020) 
   A  *DS3                                SFLPAG(0008) 

...

   A          R MSGSFLR27                 SFL          
   A  *DS4                                SFLMSGRCD(27)
   A  *DS3                                SFLMSGRCD(24)

...

   A          R SFLCTL24                  SFLCTL(SFL24)
   A  69                                  DSPMOD(*DS3) 
   A  *DS4                                SFLSIZ(0008) 
   A  *DS3                                SFLSIZ(0008) 
   A  *DS4                                SFLPAG(0008) 
   A  *DS3                                SFLPAG(0008) 

These are all the *DSn references in the display file.  I am scratching my
head at looking at these specs, so I'm afraid I can't offer much guidance
as to the why???  Also, the statement with DSPMOD(*DS3) conditioned by
*IN69?  There's no reference in the program to that indicator.

Also, for reference, in the RPG program, the way to determine whether the
display the program is running on is capable of 27x132 is:
   fFSMCPPDSP cf   e             Workstn InfDS(WInfDS)
   d* WInfDS - Workstation INFormation Data Structure
   d WInfDS          ds
   d  Num_Rows             152    153B 0                      
   d  Num_Columns          154    155B 0                      
   d* Num_******* - Returns the size capability of the display
   d*               device; either 24x80 or 27x132            

So, my uneducated first guess for you, Pat, is to stick a DSPMOD(*DS3)
conditioned by an indicator that never gets set on, in each 24x80 record. 
That probably isn't much help, as it doesn't explain why it works (for me,
anyway).

If you want me to send you the entire display file source, please email me
privately.

GA

--- Pat Barber <mboceanside@xxxxxxxxxxxxxxxx> wrote:
> I thought you could, but I ran into a problem with the compiler.
> 
> If I place a (*DS3 *DS4) at the file level, and then put a 
> dspmod(*DS4) at the record level, the compiler 
> starts whining about anything past position 80 
> as being incorrect. *DS3 would be my "regular" setting and only one
> screen needs to be *DS4.
> 
> I assume the setting at the file level and record level have to
> correct and I thought I used the exact same examples as the DDS
> manual.
> 
> Could you glance at your screens and shoot me a note ??? 
> 
> The screens are all 3488's configed as 3487HC.
> 
> 
> G Armour wrote:
> > 
> > Yes.
> > 
> > GA
> > 
> > --- Pat Barber <mboceanside@xxxxxxxxxxxxxxxx> wrote:
> > > I can't recall, but can you mix *ds3 and *ds4 screens in
> > > the "same" program ??? (*DS3 24 80  *DS4 27 132)
> > >
> > > I want to see a "normal" 24x80 on most screens but a 27x132
> > > on one screen. I don't ever recall doing one just like that.
> > 
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product search
> > http://shopping.yahoo.com
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.