Re: How far out of date are my skills

[Charles Mills]

Even if you were perfectly up-to-date today, you would be behind the curve
the second z/OS V2R4 came out. All of us are constantly learning. You'll be
fine. Go for it!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Rugen, Len
Sent: Sunday, April 22, 2018 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How far out of date are my skills

I left the Z/OS world at the version 1.6 after nearly many years of
mainframe OS and CICS work .  I see adds for telecommute Z/OS support, how
far out of date are my skills?  What should I read up on to stay current?


I know that as we moved along in Z/OS and previous version, 95% of what we
continued to use was old, some new features were exploited, but never all of
them.  Most of the change was in hardware support.  I don't miss pulling bus
and tag cables under the floor :-)


I didn't leave the mainframe, it left me.  :-)




--
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

Re: The IRS Really Needs Some New Computers

[Warren Brown]

gee, I,ve worked at both places. When IRS 6 years ago running C++ and COBOL on 
the mainframe. 

  From: Clark Morris 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Sunday, April 22, 2018 9:05 PM
 Subject: Re: The IRS Really Needs Some New Computers
   
[Default] On 18 Apr 2018 02:53:35 -0700, in bit.listserv.ibm-main
0102cb4997b0-dmarc-requ...@listserv.ua.edu (Larre Shiller) wrote:

>On Tue, 17 Apr 2018 19:19:07 -0700, Ed Jaffe  
>wrote:
>
>>On 4/17/2018 3:55 PM, Edward Gould wrote:
>>>
>>> I can’t speak to the IRS but the Social Security system (last I heard) was 
>>> *WAY* out of date by at least 20 years (maybe more). Can anyone verify (or 
>>> not), please?
>>
>>SSA runs one of the most sophisticated data centers of any government
>>agency I've seen.
>>
>>They own all the latest kit and participate in nearly every z/OS ESP. I
>>know this for FACT!
>>
>Gee, thanks Ed...!  It's certainly not easy managing 150,000MIPS of WebShpere 
>on Z, let alone the 150,000 GP MIPS of "everything else".
>
>And speaking of IT modernization efforts, I thought that this was rather 
>timely and informative:
>
>https://federalnewsradio.com/it-modernization-month-2018/2018/04/social-security-on-schedule-to-modernize-it-systems-by/
>
>...it's a 20 minute listen, but it gives you a good idea as to where we are 
>and where we are headed in the future.
>
>I guess you could get into a discussion about what we are running that is "out 
>of date", but certainly our IT infrastructure is *not*.  Are 40 year old COBOL 
>programs "out of date"...?  Well... they may have some "technical debt" 
>associated with them and sometimes maintaining them can be challenging, but 
>does it really matter if I'm running a COBOL or a JAVA program to add up a 
>column of numbers?

If you are interested in efficiency and the COBOL program has decent
record definitions, I would guess that it will do far better than
JAVA.  Has anyone coded programs in COBOL and JAVA to do the same
thing and compare them for CPU and IO consumption?  Also have they
verified the results are the same?

Clark Morris
>
>Larre Shiller
>US Social Security Administration
> 
>“The opinions expressed in this e-mail are mine personally and do not 
>necessarily reflect the opinion of the US Social Security Administration 
>and/or the US Government.”
>
>--
>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

Re: The IRS Really Needs Some New Computers

[Clark Morris]

[Default] On 18 Apr 2018 02:53:35 -0700, in bit.listserv.ibm-main
0102cb4997b0-dmarc-requ...@listserv.ua.edu (Larre Shiller) wrote:

>On Tue, 17 Apr 2018 19:19:07 -0700, Ed Jaffe  
>wrote:
>
>>On 4/17/2018 3:55 PM, Edward Gould wrote:
>>>
>>> I can’t speak to the IRS but the Social Security system (last I heard) was 
>>> *WAY* out of date by at least 20 years (maybe more). Can anyone verify (or 
>>> not), please?
>>
>>SSA runs one of the most sophisticated data centers of any government
>>agency I've seen.
>>
>>They own all the latest kit and participate in nearly every z/OS ESP. I
>>know this for FACT!
>>
>Gee, thanks Ed...!  It's certainly not easy managing 150,000MIPS of WebShpere 
>on Z, let alone the 150,000 GP MIPS of "everything else".
>
>And speaking of IT modernization efforts, I thought that this was rather 
>timely and informative:
>
>https://federalnewsradio.com/it-modernization-month-2018/2018/04/social-security-on-schedule-to-modernize-it-systems-by/
>
>...it's a 20 minute listen, but it gives you a good idea as to where we are 
>and where we are headed in the future.
>
>I guess you could get into a discussion about what we are running that is "out 
>of date", but certainly our IT infrastructure is *not*.  Are 40 year old COBOL 
>programs "out of date"...?  Well... they may have some "technical debt" 
>associated with them and sometimes maintaining them can be challenging, but 
>does it really matter if I'm running a COBOL or a JAVA program to add up a 
>column of numbers?

If you are interested in efficiency and the COBOL program has decent
record definitions, I would guess that it will do far better than
JAVA.  Has anyone coded programs in COBOL and JAVA to do the same
thing and compare them for CPU and IO consumption?  Also have they
verified the results are the same?

Clark Morris
>
>Larre Shiller
>US Social Security Administration
> 
>“The opinions expressed in this e-mail are mine personally and do not 
>necessarily reflect the opinion of the US Social Security Administration 
>and/or the US Government.”
>
>--
>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

Re: How far out of date are my skills

[Rugen, Len]

I would have been busy "Update JES2 Exits" seems to be popular in every one   
JES2 was the last subsystem I inherited from departing/retiring staff.


Since we were are a University, our mainframe was connected via TCP/IP for a 
very long time, I think even pre Z/OS.  Our first method was via RS/6000 acting 
as a router.  That was good a good skill set, I've been a AIX/Solaris/Linux 
admin since the mainframe.


Thanks for the tips.


From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Sunday, April 22, 2018 3:50:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How far out of date are my skills

Go through the z/OS migration guides.

On Sun, Apr 22, 2018 at 3:37 PM, Wayne Bickerdike  wrote:
> Shouldn't be hard to catch up. SMPE installation you may need to skill up
> on USS zFS file systems. Installation is from internet or ftp to a zFS pax
> file etc.
>
> CICS changes have been incremental nothing very different.
>
> On Mon, Apr 23, 2018 at 5:27 AM, Rugen, Len  wrote:
>
>> I left the Z/OS world at the version 1.6 after nearly many years of
>> mainframe OS and CICS work .  I see adds for telecommute Z/OS support, how
>> far out of date are my skills?  What should I read up on to stay current?
>>
>>
>> I know that as we moved along in Z/OS and previous version, 95% of what we
>> continued to use was old, some new features were exploited, but never all
>> of them.  Most of the change was in hardware support.  I don't miss pulling
>> bus and tag cables under the floor :-)
>>
>>
>> I didn't leave the mainframe, it left me.  :-)
>>
>>
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
>
> --
> Wayne V. Bickerdike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Hobart Spitz]

Somewhere, maybe in a different branch of this topic, there was a
discussion about the pros and cons of replacing Assembler with Java.  I
apologize for posting here if it's the wrong place, but I can't seem to
find the original discussion, and I have a question that seems relevant and
important, IMHO.

That's said, I can answer the question, for C/C++, as follows.  (I pose the
question for Java, below.)

*With the *nix/C record and string models, there are these issues:*

   1. Errant/unexpected/unintended pieces of binary data in a text
   file/string can break something.
   2. Separate functions/methods/techniques must be used to manipulate text
   files/strings versus binary files/string. You *must* know what you are
   dealing with up front, and/or somehow code logic for both. (I'm not sure
   the latter is possible in the general case.)
   3. Even with *nix/C oriented machine instructions, the need to inspect
   all characters up to a target point results in performance killing cache
   flooding.
   4. C++ does garbage collection resulting in "pauses" in forward
   progress, and working set, caching, and CPU spikes, among other things.

Let's call these attributes fragility, productivity, and efficiency,
respectively, for the convenience convenience.  C has issue with these
characteristics.

As most of the readers here know, mainframe style records and strings do
not suffer from these limitation.  When the length of a string/record is
known external to the data contents, you can manipulate any platform-native
data in z/OS, z/VM without it breaking due to something in the data, you
write the same code regardless of what you are dealing with, and, less
obviously, any activity that skips a cache can avoid a cache line promotion
saving processor resources.

So, my "burning" question for Java is, which, if any, of these above issues
(data fragility, coding productivity, efficiency, and garbage collections)
does Java share with C/C++.

If Java suffers from all or most of the issues, then I would say replacing
Assembler with Java is pretty much out of the question.  On the other hand,
if Java suffers few or none of the above issues, it might be viable to
replace Assembler with Java (ignoring other issues, like cost, testing,
compatibility, data porting, etc.)

To sum up:  Does Java use a similar record/string model to that of C/C++,
and does it do garbage collection similarly.

Thanks in advance for satisfying my curiosity.











OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Sat, Apr 21, 2018 at 12:29 PM, Barry Merrill  wrote:

> In 1975 there was a BOF, Bird's of a Feather Session on Year 2000 Concerns
> at the SPRING SHARE meeting, as I recall.  BOF's were spontaneous evening
> meetings posted/scheduled usually that day.
>
> Barry
>
>
> Herbert W. “Barry” Merrill, PhD
> President-Programmer
> Merrill Consultants
> MXG Software
> 10717 Cromwell Drive
> Dallas, TX 75229
> www.mxg.com
> ba...@mxg.com
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, April 20, 2018 5:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New
> Hardware (nextgov.com)
>
> On Fri, 20 Apr 2018 19:25:54 +, Lester, Bob wrote:
> >
> >I agree with both you and Gil.  But, how many programmers in the 60s,
> 70s, even 80s were thinking about Y2K?  Sure, the really good ones were,
> but what about the other 80%?
> >
> >and, Y2K came off without a hitch...(FSVO - "hitch")
>
>
> >-Original Message-
> >From: IBM Mainframe Discussion List Porowski, Kenneth
> >Sent: Friday, April 20, 2018 1:20 PM
> >
> >That was due to lack of foresight by the programmer not due to the age of
> the system.
> >
> True in the sense that it affected one-year-old computers as much as older
> computers running th same software.
>
> I'm disappointed that this thread has so much focused on Y2K which I meant
> only as an extreme example.  Things change.  Y2K was only more precisely
> forseeable.
>
> Increasing complexity of the tax code requires new logic.  Inflation and
> rate escalation may have made some data fields inadequate in size.
> E-filing requires network interfaces and code to support them and causes
> the one-day spike in workload.  I gather from these fora that COBOL is not
> comfortably suited to TCP/IP.  IBM bet that SNA/VTAM could crush TCP/IP and
> customers were the losers.  IBM bet that EBCDIC could crush ASCII and
> customers were the losers.  And customers bet that COBOL skills would
> remain in the forefront of availability.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 

Re: IDC3321I ** OPEN/CLOSE/EOV ABEND EXIT TAKEN

[Lizette Koehler]

What are you trying to do with the Couple Dataset for WLM?

Making a backup?

Transferring it to a another system to use?

Other?

CDS datasets are not like normal VSAM.  The unities to create it, should be 
used to handle it.

If you can provide details of what you want to do, we can probably give better 
answers.

My first guess is you did not provide enough attributes.  Since you did not 
supply the complete error message, it is just a guess.

You may need, LRECL,  BLKSIZE, RECFM on the output file


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> johnnydeep san
> Sent: Sunday, April 22, 2018 11:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IDC3321I ** OPEN/CLOSE/EOV ABEND EXIT TAKEN
> 
> hello All,
> 
> I'm trying to repro  WLM couple dataset to ps file , getting IDC3321I and
> below given my jcl . help me on this .
> 
> 
> 
> //SYSPRINT DD SYSOUT=A
> //INDD  DD DSN=SYS1.ADCDPL.WLM.CDS01,DISP=SHR
> //OUDD  DD DSN=IBMUSER.WLM.PE,DISP=(NEW,CATLG),
> //  SPACE=(CYL,(250,10)),UNIT=SYSDA,
> //  DCB=(LRECL=4096)
> //SYSIN DD *
>  REPRO  -
>INFILE(INDD) -
>OUTFILE(OUDD)
> /*
> 

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

Re: How far out of date are my skills

[Mike Schwab]

Go through the z/OS migration guides.

On Sun, Apr 22, 2018 at 3:37 PM, Wayne Bickerdike  wrote:
> Shouldn't be hard to catch up. SMPE installation you may need to skill up
> on USS zFS file systems. Installation is from internet or ftp to a zFS pax
> file etc.
>
> CICS changes have been incremental nothing very different.
>
> On Mon, Apr 23, 2018 at 5:27 AM, Rugen, Len  wrote:
>
>> I left the Z/OS world at the version 1.6 after nearly many years of
>> mainframe OS and CICS work .  I see adds for telecommute Z/OS support, how
>> far out of date are my skills?  What should I read up on to stay current?
>>
>>
>> I know that as we moved along in Z/OS and previous version, 95% of what we
>> continued to use was old, some new features were exploited, but never all
>> of them.  Most of the change was in hardware support.  I don't miss pulling
>> bus and tag cables under the floor :-)
>>
>>
>> I didn't leave the mainframe, it left me.  :-)
>>
>>
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
>
> --
> Wayne V. Bickerdike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: DFSMSdss dump fix after binary transfer

[Wayne Bickerdike]

I always take a peek at the DCB attributes of the tersed file and
preallocate the same on the receiving system. FTP is then simply binary and
get/put into the newly allocated file.

On Sun, Apr 22, 2018 at 11:52 PM, CM Poncelet  wrote:

> 'm afraid I can't help much with this. I FTP'd from mainframe to
> mainframe server, but not to/from my PC (I used TN3270 Plus or QWS3270
> for that).
>
> However, from vague memory, tersed files used to have to be RECFM=FB
> BLKSIZE=6144 LRECL=1024 and the PGM=FTP step's SYSIN required a LOCSITE
>  and BINARY before the "GET  '' (REPLACE"
> card. The PGM=TRSMAIN,PARM=UNPACK ran as a separate step, afterwards.
>
> Cheers, CP
>
>
> On 21/04/2018 10:27, Wayne Bickerdike wrote:
> > I always terse the dump first, seems problematic if you don't.
> >
> > ADRDDSU DUMP, TERSE, FTP in Binary.
> >
> > Reverse the process on the next MVS platform.
> >
> > On Sat, Apr 21, 2018 at 4:03 PM, CM Poncelet 
> wrote:
> >
> >> (a) Is the original ADDRSSU dump dataset still on the mainframe? If yes
> >> transfer it to a *.dat (or *.bin) file on the PC, using e.g. TN3270
> >> Plus, and as binary (no EBCDIC to ASCII). You should then be able to
> >> upload that from the PC to a preallocated mainframe dataset (specifying
> >> BLKSIZE=27998).
> >> (b) If the original dump dataset is no longer on the mainframe, *how*
> >> was it transferred to the PC and to what file extension? If not to .dat
> >> or .bin and the PC's OS is Windows, the file will need to be renamed to
> >> *.dat (or *.bin) *after* it has been backed up 'just in case'. You
> >> should then be able to upload it to a preallocated mainframe dataset
> >> with BLKSIZE=27998 using e.g. TN3270 Plus.
> >> (c) Else, please explain how the dump dataset was uploaded to the PC and
> >> to what file name.extension - and also what the PC's OS is.
> >>
> >> Thanks, CP (retired sysprog)
> >>
> >>
> >>
> >> On 20/04/2018 15:35, Jerry Paper wrote:
> >>> Hello all,
> >>>
> >>> this one is for the old-timers on the list (I guess :).
> >>> A colleague has made a logical data set DUMP of important data and
> >> downloaded to his PC in binary (by mistake, without additional steps).
> As
> >> expected, after uploading from PC to z/OS, the format is broken, and
> >> ADRDSSU doesn't recognize the DUMP (uploaded as blksize=27998, lrecl=0,
> >> recfm=u).
> >>> Any recovery ideas for this situation, how to recover the PC data to a
> >> RESTORE-able dataset? :)
> >>> Thanks!
> >>>
> >>> Jerry
> >>> Mainframe Operations
> >>>
> >>> --
> >>> 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
>



-- 
Wayne V. Bickerdike

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

Re: How far out of date are my skills

[Wayne Bickerdike]

Shouldn't be hard to catch up. SMPE installation you may need to skill up
on USS zFS file systems. Installation is from internet or ftp to a zFS pax
file etc.

CICS changes have been incremental nothing very different.

On Mon, Apr 23, 2018 at 5:27 AM, Rugen, Len  wrote:

> I left the Z/OS world at the version 1.6 after nearly many years of
> mainframe OS and CICS work .  I see adds for telecommute Z/OS support, how
> far out of date are my skills?  What should I read up on to stay current?
>
>
> I know that as we moved along in Z/OS and previous version, 95% of what we
> continued to use was old, some new features were exploited, but never all
> of them.  Most of the change was in hardware support.  I don't miss pulling
> bus and tag cables under the floor :-)
>
>
> I didn't leave the mainframe, it left me.  :-)
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

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

How far out of date are my skills

[Rugen, Len]

I left the Z/OS world at the version 1.6 after nearly many years of mainframe 
OS and CICS work .  I see adds for telecommute Z/OS support, how far out of 
date are my skills?  What should I read up on to stay current?


I know that as we moved along in Z/OS and previous version, 95% of what we 
continued to use was old, some new features were exploited, but never all of 
them.  Most of the change was in hardware support.  I don't miss pulling bus 
and tag cables under the floor :-)


I didn't leave the mainframe, it left me.  :-)




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

IDC3321I ** OPEN/CLOSE/EOV ABEND EXIT TAKEN

[johnnydeep san]

hello All,

I'm trying to repro  WLM couple dataset to ps file , getting IDC3321I and
below given my jcl . help me on this .



//SYSPRINT DD SYSOUT=A
//INDD  DD DSN=SYS1.ADCDPL.WLM.CDS01,DISP=SHR
//OUDD  DD DSN=IBMUSER.WLM.PE,DISP=(NEW,CATLG),
//  SPACE=(CYL,(250,10)),UNIT=SYSDA,
//  DCB=(LRECL=4096)
//SYSIN DD *
 REPRO  -
   INFILE(INDD) -
   OUTFILE(OUDD)
/*

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

Re: Mass submit jcl

[Lizette Koehler]

I believe this is an effort hat is easily handled by a scheduling software.

However, I had to do something like this, and I wrote all my SYSOUT from the JOB
to a dataset, then the last step would parse it to see if the next job could be
submitted. 

RC=04 was not always a good thing.  And the process had to account for new or
renamed members.  Or someone adding something to the dataset not expected.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Daniel S. Dalby
> Sent: Saturday, April 21, 2018 11:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Mass submit jcl
> 
> Hi Lizette,
> 
> My thought was that the poster could submit the members in alphabetic
> sequence.
> As the job was submitted it would tack on an additional step to the end to go
> through the submission library and submit the NEXT member IF the return code
> was zero.  Each step as they got submitted would add the additional step to
> indicate where it came from and what member the current JCL came from.  The
> last step would check if there is another member after this one in the
> library and submit it along with the additional step ... and so on until a
> non-zero return code is encountered or the last member is submitted.
> 
> As you suggested, a scheduler would be the best method but the original
> poster didn't say if they had one or not.
> I don't know if the new IBM SCHEDULE statements allow for return code
> checking in a submission chain.
> 
> Also, by sequentially submitting the jobs in alphabetical sequence and not
> submitting the next until the previous job has completed successfully, you
> won't get jobs running out of order.
> 
> DanD
> 
> "Lizette Koehler"  wrote in message
> news:<0bd601d3d993$0e7d02d0$2b770870$@mindspring.com>...
> > Do you have a job scheduling software?  If not, then submitting in a
> specific
> > sequence will be tricky
> >
> > Are you at z/OS V2.3?  If so, JES2 now has some scheduling control
> > cards
> that
> > will allow you to do simple scheduling functions.
> >
> > Check on www.cbttape.org for scheduling functions.
> >
> >
> > If the jobnames are different, the when they hit the input queue they
> might run
> > out of order.
> >
> > If you provide more specific details, we might provide better answers
> >
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf
> Of
> > > Daniel S. Dalby
> > > Sent: Saturday, April 21, 2018 9:36 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Mass submit jcl
> > >
> > >  wrote in message
> > > news:<6462565f-68ca-445b-9226-b25257e1e...@googlegroups.com>...
> > > > Is there any methods for submitting all the members in a pds in
> > > > order and
> > > do return code checking at the job level so that job b is depends on
> joba
> > > rc=0 etc
> > >
> > > ---
> > >
> > > You'd get better response if you submitted to the mailing list
> > > rather
> than
> > > posting to the newsgroup.  Fortunately some of us read from the
> newsgroup
> > > which contains both.
> > >
> > > Here's a challenge to yourself or anyone interested in playing for a
> > > few hours.  I'm busy this weekend otherwise I'd give it a try.
> > >
> > > Create a procedure "SUBNEXT" where you pass it a PDS/PDSE library
> > > name
> and
> > > the current member.  Write it in whatever language you are most
> comfortable.
> > > A CLIST or REXX could be used as the PROC could contain "//substep
> > > EXEC PGM=IKJEFT1A,PARM='%SUBNEXT  '".
> > >
> > > The SUBNEXT program would allocate the library, create a member
> > > list,
> find
> > > the current member and check if another member follows, if so submit
> that
> > > member.
> > > The routine could dynamically allocate the INTRDR and using an
> > > ACB/RPL
> submit
> > > via PUT the JCL onto the internal reader and at the END of that
> > > input
> member
> > > add ...
> > > "//LASTSTEP EXEC SUBNEXT,DSNAME=dsname,MEMBER=mem,COND=(0,NE)".
> > >
> > > When using an ACB/RPL to write to the internal reader after you
> > > issue
> ENDREQ
> > > the RPLRBAR field will contain the 8 character job id, which can be
> > > used
> in
> > > any messages if you wish.
> > > It would be nice to have another step following the "SUBNEXT" step
> > > that issues a write to operator if SUBNEXT was NOT executed.  I
> > > guess that
> could
> > > be up to the user if they wanted that functionality.
> > >
> > > SUBNEXT would NOT be a mass submission of the PDS/PDSE but rather
> sequential
> > > submission of the members within that library.  By using COND=
> submission
> > > would STOP whenever a job does NOT work as expected (in this example
> > > the
> job
> > > does not end with a return code of zero.
> > >
> > > If nobody attempts this in the next few days, I'll give it a shot.
> > > I
> could
> > > find this useful for submitting a TEST job streams.
> > >
> > > 

Re: DFSMSdss dump fix after binary transfer

[CM Poncelet]

'm afraid I can't help much with this. I FTP'd from mainframe to
mainframe server, but not to/from my PC (I used TN3270 Plus or QWS3270
for that).
 
However, from vague memory, tersed files used to have to be RECFM=FB
BLKSIZE=6144 LRECL=1024 and the PGM=FTP step's SYSIN required a LOCSITE
 and BINARY before the "GET  '' (REPLACE"
card. The PGM=TRSMAIN,PARM=UNPACK ran as a separate step, afterwards.
 
Cheers, CP
 

On 21/04/2018 10:27, Wayne Bickerdike wrote:
> I always terse the dump first, seems problematic if you don't.
>
> ADRDDSU DUMP, TERSE, FTP in Binary.
>
> Reverse the process on the next MVS platform.
>
> On Sat, Apr 21, 2018 at 4:03 PM, CM Poncelet  wrote:
>
>> (a) Is the original ADDRSSU dump dataset still on the mainframe? If yes
>> transfer it to a *.dat (or *.bin) file on the PC, using e.g. TN3270
>> Plus, and as binary (no EBCDIC to ASCII). You should then be able to
>> upload that from the PC to a preallocated mainframe dataset (specifying
>> BLKSIZE=27998).
>> (b) If the original dump dataset is no longer on the mainframe, *how*
>> was it transferred to the PC and to what file extension? If not to .dat
>> or .bin and the PC's OS is Windows, the file will need to be renamed to
>> *.dat (or *.bin) *after* it has been backed up 'just in case'. You
>> should then be able to upload it to a preallocated mainframe dataset
>> with BLKSIZE=27998 using e.g. TN3270 Plus.
>> (c) Else, please explain how the dump dataset was uploaded to the PC and
>> to what file name.extension - and also what the PC's OS is.
>>
>> Thanks, CP (retired sysprog)
>>
>>
>>
>> On 20/04/2018 15:35, Jerry Paper wrote:
>>> Hello all,
>>>
>>> this one is for the old-timers on the list (I guess :).
>>> A colleague has made a logical data set DUMP of important data and
>> downloaded to his PC in binary (by mistake, without additional steps). As
>> expected, after uploading from PC to z/OS, the format is broken, and
>> ADRDSSU doesn't recognize the DUMP (uploaded as blksize=27998, lrecl=0,
>> recfm=u).
>>> Any recovery ideas for this situation, how to recover the PC data to a
>> RESTORE-able dataset? :)
>>> Thanks!
>>>
>>> Jerry
>>> Mainframe Operations
>>>
>>> --
>>> 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