Its utility will depend on the quality of the code it produces. Can it be 
trained to produce clean maintainable code?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Sunday, May 21, 2023 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XEDUT vs. ISPF (was: Typo ...)

> On 22 May 2023, at 8:15 am, Farley, Peter 
> <0000031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
> Please explain what "co-pilot" in this context means.  I am not familiar with 
> that reference.

Github co-pilot is an AI programming assistant. You can ask it to do things 
like write a search algorithm or a Java servlet application. It’s powered by 
OpenAI the deep learning technology used by ChatGPT. It builds its language 
model from millions of lines of open source code. I’m interested if it could be 
trained on large legacy code bases written in languages like COBOL. This would 
be very useful onboarding next gen developers as the inevitable skills shortage 
is already starting to bite.

I doubt that ISPF will be used by next gen devs who are being trained to use VS 
Code which supports copilot. It’s not just for GUI IDEs though, Microsoft have 
released a Vim (neovim) plugin https://github.com/github/copilot.vim.

>
> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of 
> David Crayford
> Sent: Sunday, May 21, 2023 7:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: XEDUT vs. ISPF (was: Typo ...)
>
> Has anybody developed a co-pilot plugin for ISPF yet? :)
>
>> On 21 May 2023, at 3:42 pm, Seymour J Metz <sme...@gmu.edu> wrote:
>>
>> Well, I am a TSO bigot and grew up on CLIST, but once I had REXX available 
>> in TSO/E I bid CLIST a fond AMF. As is common in such cases, while REXX is 
>> in general far better than EXEC2 and CLIST, there are things that that it 
>> lacks.
>>
>> ISPF versus XEDIT is harder.ISPF has significant advantages as an 
>> application framework, and ISPF/PDF EDIT has some nice features that XEDIT 
>> lacks, but XEDIT is on balance a much better editor.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> ________________________________________
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>> behalf of Jack Zukt [jzuk...@gmail.com]
>> Sent: Saturday, May 20, 2023 3:55 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: XEDUT vs. ISPF (was: Typo ...)
>>
>> Hi,
>> That made for some interesting reading. I was quite proficient with
>> REXX and XEDIT before moving to MVS and ISPF. The first MVS I worked
>> with did not yet have REXX. It was helish doing the transition to ISPF and 
>> CLIST.
>> I still find VM help much better than MVS's. One of the first things
>> that I do when starting on a new MVS system is to put an edit macro
>> named QQ on the SYSPROC or SYSEXEC concatenation, so that I do not
>> have to write CANCEL. I really do not like having that on a pfkey. Too
>> much grief because of that.
>> I find that XEDIT environment capabilities permit us to tailor our
>> working environment far more than ISPF but, as always, I think that
>> has more to do with our path than with the products themselves.
>> As I said at the beginning, it really was an interesting reading.
>> Regards
>> Jack
>>
>>> On Sat, May 20, 2023, 00:08 Paul Gilmartin <
>>> 0000042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>>>
>>>> On Fri, 19 May 2023 18:32:57 -0400, Phil Smith III wrote:
>>>>  ...
>>>>> I was trying to automate that in a macro on PF3.
>>>>
>>>> Yeah, that makes sense.
>>>>
>>> I learned a smattering of ISPF before any XEDIT; the latter in the
>>> era before PQUIT and QQIT intruded: the wrong solution.  But I
>>> immediately longed for ISPF's smart END which did a Save only when
>>> needed and left the timestamp unchanged otherwise.
>>>
>>> And I was irritated by XEDIT's behavior of *always* scrolling to
>>> center the target of a successful search, usually needlessly
>>>
>>> And it was disappointing that the XEDIT-based *LIST menus always ran
>>> in separate rings, never sharing with each other, PEEK, and XEDIT.
>>> They should have used ADDRESS XEDIT instead of CMS.
>>>
>>> I wasted too much time scripting around such things, never modifying
>>> IBM code, only using undocumented interfaces.
>>> And it all went for naught when a major update broke them
>>>
> --
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to