× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Altering field display attributes by user without touching DSPF source
  • From: "Steve Richter" <srichter@xxxxxxxxxxxxx>
  • Date: Tue, 24 Apr 2001 11:08:16 -0400

Graham,

sounds like a job for "ovrdspf".  if user = "peon" then OvrDspf to version
of dspf that has dspatr(nd) on the gross profit display flds, if user =
"boss" then OvrDspf to version that shows the gross profit display flds.

but if you are interested in the 5250 data stream approach ...

the following manual documents how a "C" pgm on the pc can function as a
client access pc5250 display session.
    Title: Client Access/400 PC5250 Programmer's Guide
    Document Number: SC41-3554-01

The pgm effectively receives the display screen in a 24x80 buffer. The pgm
can then do what it wants with this display. It can call an api to return
input data and a cmd key to the as400, it can extract the dsplay flds from
the buffer and display them in a window on the pc, ...  ( but I dont think
it can manipulate it and pass it along to the 5250 dsply session )

this is called ehlappi programming and is something ibm provided first on
the mainframe and then on the as400.

an example of its realistic use is a situation where you have a transaction
file that originates from another system ( a spreadsheet of customer
accounts ).  the only way you can safely add a new cust to the order entry
system is thru the cust entry display pgm.

 Instead of having a user manually enter each cust in the spreadsheet into
the order entry system, you write a EHLLAPI pgm that
     "signs on" to the system,
     "selects the menu option" to add a new customer,
     reads a rcd from the spreadsheet,
     fills the EHLAPPI input buffer with the cust entry dsply flds exactly
where they would appear on the screen,
     then calls the ehllapi api to "press the enter key" and send the screen
to the as400.

Steve Richter
as400, windows c++ contract programmer.


-----Original Message-----
From: Smith, Graham (EBM) <Graham_SmithEBM@heinz.co.uk>
To: 'MIDRANGE-L@midrange.com' <MIDRANGE-L@midrange.com>
Date: Tuesday, April 24, 2001 8:38 AM
Subject: Altering field display attributes by user without touching DSPF
source


>We're running a ERP package, BPCS as it happens, and the company is after
>some form of field level security by user.
>
>They're basically looking to protect or non-display specific fields.
>
>We've identified 50 odd programs with affected display files.
>
>We don't want to go and modify the program code.
>
>We've considered  copying the dspf source and creating a set of Display
>files in a separate library with the particular fields DDS attributes set
to
>PR/ND and loading this library higher in the library list than the std DSPF
>based on user.
>
>Is there any way of grabbing the buffer or bit stream sent to the display
>(5250 emulation used in all cases I believe) and altering the attribute
>settings at that point?  If so how and what skill set would we need to
>acheive this?
>
>Thanks in advance
>
>
>
>
>Regards
>
>Graham Smith
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>EBM Project
>Hayes Park,
>Telephone + 44 208 848 2585
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>**********************************************************************
> This email and any attachments are confidential and solely
> for the use of the intended recipient.  They may contain
> material protected by legal professional or other privilege.
> If you are not the intended recipient or the person responsible
> for delivering to the intended recipient, you are not authorised
> to and must not disclose, copy, distribute or retain this email
> or its attachments.  Although this email and its attachments
> are believed to be free of any virus or other defect, it is the
> responsibility of the recipient to ensure that they are virus free
> and no responsibility is accepted by the company for any
> loss or damage arising from receipt or use thereof.
>
>**********************************************************************
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
david@midrange.com
>+---
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.