Re: GCIC Fullscreen applications

"paoloG" <[email protected]>
Newsgroups gmane.comp.emulators.hercules390.vm
Message-ID <[email protected]>







--- In [email protected], "Rocky" <rocsystems@...> wrote:
>
> Yup
>  
> It shoud work on Sp/5 100% compatible
>  
> The NUCON is slightly different but the parts that I use are the SAME. Just
> need BC MODE.
> I think for SP/6 there are few modifications that would have to be made in
> NUCCON,
>  
> and FOR X/A and forward I think BC mode is gone and that would need some
> fixing of my kernel to pick up the interrupts from128-129
> instead of the  IOPSW. 
>  
> Also have to be careful if a system routine is going to return an address
> with 31 bit addressing instead of 24.
> LA instructions in 31 bit addressing could cause a problem.
>  
> Might need some modification there as well. But SP5 and SP6 should work with
> no problems.
>  
> Also the new routines that I am finisihng up really make it a different
> product
>  
> I added : FIND  CHANGE NULLS and TRUNC commands
> I actually wrote all the routines using the GCIC EDITOR - It's not X-EDIT
> but I figured that the best test I could give it was to actually use it.
> With the new routines its not bad at all.
>  
> I went crazy without the FIND COMMAND so I added that,
>  
> I needed the TRUNC COMMAND for the CHANGE ROUTINE and I figured the NULL
> couldn't hurt.Allso will need that for the variable len records.
>  
> Made a few modifications to the screens as well. We are travelling a lot
> this week, so I have less time to work on it But I only have 2 1/2 routines
> left to fix.
>  
> The Variable length record problem - make them longer with the editor and
> the HEX display.
> and some positioning issues after the Change and RESET  commands.
>  
> And of course the HEX display - haven;t decide yet what to do with that,
> That is the LAST REAL routine that is missing I think.
>  
> CHANGE is working - that was a real complicated routine  And I am not happy
> with the algorythm we decided on.
>  
> For instance all my assembler programs have sequence numbers in pos 73-80.
>  
> We bypassed that problem with trunc command - thank you for remebering that
> - otherwise we would never have been able to change anything to a longer
> field.
>  
> But the way we decided to to do the change - if the the new field is longer
> than the first
> I need blanks  exactly at the trunc position and immediately precedding it.
>  
> I would have rather searched for multiple blanks starting from the trunc
> position and going backwards if they were at the end fine.
> But if  there aren't enough there, then I could elimate some more from the
> body of the the line.
> While testing the new routine out on live data - writing code and testing -
> I ran across these problems several times.
>  
> If I have a comment in pos 50-69 and there are  lots of them in assembler.
> And  I want to change a label in pos1 from "UP" to "MOVEUP" it wont work.
> cant do it.
> you can change /UP    /MOVEUP/ but not /up/moveup/ - not enough blanks at
> the TRUNC POS.
>  
> But I have plenty of room to elimate consecutive blanks between 40 and 50 or
> even within the comment
>  
> We didn't think this out enough. SEEMSl like we were stuck the logic of
> ASSCI TEXT files and didn't really analyse  or understand the problem. of
> fixed lenght records.
>  
> The old version of X-edit that I tested just moved the data and lost the
> comment -  No message no warning.
> But a recent version ISPF EDIT did it correctly
> Or what I think is correct.
>  
> We were thinking in terms of word processors or text editors where
> positioning can always come at the end of the record.
> Someone actually gave me an example of how Wordpad does it. Forgetting that
> we can't just add data to a record.
>  
> I think we made a mistake - but I don't use change all that much so it's
> livable.
> Like I said when I asked for the ALGORYTM , I am not going to write it
> Twice, 
> At least It gives a message and does not destroy data Like the old X-EDIT
> did,
>  
>  
> YOu will enjoy the new version - Next week I hope
> If you have any other Cosmetic stuff - Like PF's and my spelling - let me
> know and I;ll put them in the next release.
> Do you have a better Idea than PF5 for the repeat FIND - I use that a lot
> and it wasn't comfortable - Maybe it;s just getting used to it.
> ---------------------------
> Also - do you think that there is any way for program that is working in
> disconect mode to connect itself to a GRAF.
> without  a user doing a LOGON and reconnecting
>  
> I was thinking of a way to use it comfortably as a single user interface. It
> now disconnects automatically.
> Youi can the do dial immediatley and work.
> I can end the job from the program and relese the graph I am using
> But then how do I logon again without logging on. Not the end of the world
> to LOG ON but would love to automate it.
> Without changing the System... Remember we are VANILLA VM/370
>  
> Roc
>  
>

Rocky,

I was already confortable with '/' search existing function (no need to type 'FIND /' for me; to repeat FIND you could tipe '=' instead of PF5 and let it operative so you can hit ENTER and go to next instance and so on until you cancel it in the comamnd line.

The change algorythm is very good in my opinion; I was already happy with X-edit style to trunc everything after column 71.
I would do: ch /DS/DC/ changes only the current line (if DS exists)and ch /DS/DC/ * changes all the occurrences in the file.

To connect automatically I would issue the following commands in GCIC 
after disconnession (suppose the terminal is at address 21 and that 49F is not defined by GCIC as DEF GRAF):

CP DET 49F CMSUSER (if it was already attached)
CP DISA 21
CP ATT 21 CMSUSER 49F

On terminal 21 an ENTER shows the application screen
On exit a message asks if the user wants go on with GCIC or exit; in this case:

CP DET 49F CMSUSER
CP ENA 21

Regards and compliments for the execellent job.

Paul
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.